Sorry to post two responses - I thought I'd give counter points to the specifics above - and again this isn't the best forum to discuss these.

• Human readable. I like human readability. DXF is fairly human readable (sort of). In the proposed system, once you have found a line it is easier to change the X coordinate. However, it is probably only a little bit easier to find a line in the proposed system than it is in a DXF. If you have a database filesystem, search would help you find it even more quickly.
• If it can be a separate file, then that's what it should be. One should never make a blanket statement. ;) There should be a limit to granularity. Exploring those limits is an exercise to the implementor. Putting each line entity or each point entity into a separate file may be pushing the limits a bit (I know ReiserFS would love it though).
• Fast efficient saving - No arguments here
• Fast efficient reading - No arguments here either
• Infinite undo. - Well - undo to what level - this only applies if each modification, no matter how small, uses a CVS commit. With this the CVS storage files would become huge over time and would be fairly slow on a remote CVS repository. Without this you get undo with steps that consist of revision saves of the entire document.
• Changes are easily encapsulated and portable - Love this one also. Great idea. CVS is perfect for this - but is probably pretty good for DXF as well.
• Full version tagging and release management - Plain text DXF or drawingXML would offer the same features.
• Embedded resources are kept external - XREF's in drawings already are - same with raster image data.
• Fine-grained permissions system - Already have this with external references - The proposed system gives you granularity to the line level (which is probably extreme) - Any inserted block that you would want permissions on may already be an XREF anyway and could have permissions control.
• Platform-independent data - Any plaintext version or database backend could be this way.
• Object-oriented data - Existing CAD systems already are - to the extent that you use the object oriented nature of blocks.

I am not writing this to discourage the use of the proposed system - it is a very well thought out and useful system and I find it intriguing and kind of cool. But I am suggesting that the features it offers can already be found in many of the existing CAD file formats. I would consider this "just another CAD format," or maybe "just a better-than-most CAD format." It is a good one, but any CAD program will operate independent of the file format. Features of the format are just gravy.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.