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.
my @a=qw(random brilliant braindead); print $a[rand(@a)];
