[freearchitecture] An open CAD file format

[Bruno Postle]

On Mon 17-Feb-2003 at 01:30:24AM -0500, Steve Hall wrote:
> 
> Still digesting this. It was a good read and I'm still trying to get
> my head around it. Some random ponderings as I think:
> 
> * Not sure if the CAD file is in CVS or on my hard drive.
> 
>   If it lives in CVS, then file management from my hdd is irrelevant,
>   I don't care about what it looks like there, I shouldn't even see
>   it. But what if I want to mail it home to work on?

You don't email it to yourself, that's the sort of versioning
nightmare that CVS is designed to avoid; you just go home and type
`cvs update` to synchronise your home copy with the work copy.

Once you are finished at home, you just type `cvs commit`.  When you
get back into the office, you sit down and type `cvs update` - This
is how we work with source-code and it's wonderful, really it's
liberating.

CVS is a system where you always work on normal files on your local
hard-disk, the CVS bit is just something you do to keep that work
safe, logged and universally available.

>   If it lives on disk in zip format, I can easily put it to CD and
>   distribute.

The zip thing is a red herring, generally the drawing would exist in
the plain text form - Zipping it into one file is something you
would only do for archiving and emailing (though you can avoid
emailing entirely if your CVS repository is publicly readable).

>   It seems there's a conflict between CVS versioning and the file
>   store idea. I can't figure out how to at the same time share the
>   file as one glob, maintain locking for select atoms, and maintain
>   its versioning all at the same time.

That's the magic of CVS, if anyone wants to get hold of a particular
drawing from the repository, they just type something like `cvs
checkout cooldrawing`.  If they want a previously tagged "stable"
version, they type `cvs checkout -r revision-b cooldrawing`.

Of course, all this can be made non-scary with many free
pointy-clicky GUI tools.

> * Seems like both ideas also make file management secondary with the
>   database primary. An SQL file format would require export. The file
>   store uses a compressed package which seems to conflict with the
>   need for (optional) limited internal locking for objects under
>   current edit or reference.

I shouldn't have mentioned that whole zip file thing :-).

> * Not sure either would be as portable or transmutable as something
>   like XML. It would be a shame to re-invent yet another data format
>   when there are so many good XML code libraries already out there.

It may sound heretical, but XML is terrible in versioning systems.

XML is (quite properly) whitespace insensitive, this means that both
these chunks of xml are identical:

    <foo bar="abcdef" baz="ghijkl">Hello World</foo>

    <foo
        baz = "ghijkl"
        bar = "abcdef"
        >hello World<
    /foo>

Needless to say, diff and patch (and therefore CVS) see these two as
entirely different - So you end up requiring that all applications
maintain the same XML formatting conventions.

(XML and CVS work fine together when you are hand editing the files).

> * CVS doesn't lend itself to thousands of tiny files. It's better with
>   fewer files each containing a larger set of atoms.

I don't know that that is the case, CVS _does_ have lots of
stupidities that projects like Subversion are trying to avoid.

>   This seems at odds with the important notion that "multiple
>   users can edit the same drawing at the same time."

I shouldn't have mentioned that either ;-).  It's in the nature of
CVS that two people can edit different parts of the same file at the
same time - The server will try and resolve conflicts at the `cvs
commit` stage.

Yes, it's completely pointless to have two people working on the
same checked-out local copy, they might as well checkout a copy
each; however, I can think of lots of reasons why _one_ person might
want to have the same drawing open several times all at once.

> * Persistent names seems ok as long as it's only for unique
>   identification. Sounds like a trap to avoid if the embedded
>   meta-data within the name gets used for anything else though.

These namespace problems will always exist:

    Block name (or ?): foo
    Block FOO already exists.
    Redefine it? <N> n
    Command: *Cancel*

An automatically generated name should be proveably unique, whereas
a user generated name should be absolutely descriptive to prevent
other people recreating the same object unnecessarily.

> * One line per data item--for readability or parsing? Same could be
>   accomplished with XML or some folding tree thingy, too.

Really I'm pretty agnostic about XML, it's just that splitting data
into small file chunks is incredibly effective when you need to
manipulate the data with ad-hoc tools.

Also, a monolithic XML file has to be regenerated from scratch every
time it needs to be updated - Pretty horrible when you have many
MegaBytes of information.

> * Object properties stored in lookup tables is quite sensible.

He he, that's the bit I wasn't sure about...

> * Blocks, Xrefs, groups and symbols are all the same thing--yes, in my
>   mind, this it the one thing AutoCAD got right.

Except that there is no polymorphism.

For example, I can't simply create a new door that is exactly the
same as all the other doors except with the handle six inches lower.

If I want this, I have to go back to the original door.dwg and make
it an option - With unpredictable consequences in all the other
drawings that also use the same object.  I may not even have the
file access permissions to mess around with such a basic file anyway.

In this office we hardly use Xrefs at all for these sort of reasons.

(I use them a lot with portable-building-systems that necessarily
have a limited number of pre-existing components)

>   Although I believe our new generation CAD file is already
>   abstracting the data still further to include rasters, spec
>   data, schedule, bid, etc., really anything.

This is what I can't stand about .dwg (and similarly .doc), crazy
stuff like embedding simple JPEGs into a proprietary file format
where I can't edit them without buying a copy of AutoCAD.

-- 
Bruno