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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.