Re: XML file formats .... was: Re: gEDA-user: Some footprints I tried to create

[Magnus Danielson <cfmd@xxxxxxxxxxxx>]

From: Stuart Brorson <sdb@xxxxxxxxxx>
Subject: XML file formats .... was: Re: gEDA-user: Some footprints I tried to create
Date: Wed, 14 Mar 2007 16:59:37 -0400 (EDT)
Message-ID: <Pine.BSF.4.64.0703141636190.77944@xxxxxxxxxxxxxxxxxxxx>

Stuart,

> > Sounds like a job for XML :-) .  Really, I don't see the big deal. If you 
> > would like am XML format, write a parser that will take the current format 
> > and generate XML to and from that. This could be located in the File->Export 
> > / File->Import menu (or something like that). Now you get your XML and others 
> > can keep what they currently use.
> 
> I don't want to go into great detail about the argument against XML
> again.  I'll observe that we have this same debate about XML file
> formats every two or three years.  I think it has to do with how long
> it takes us to lose our institutional memory due to churn on the
> mailing list.
> 
> Maybe I'll write an item for the FAQ about why we don't junk the file
> format in favor of XML.

Please do!

> *  The other benefit of XML is that it is more-or-less human
> readable.  I'll grant that this is a valid assertion.  Our current
> file format is not readable by a human who has never read the
> documentation.  However, our current file format *is* ASCII, and is
> completely documented, so an essential reason for readability -- the
> ability to write scripts against the file -- is already taken care
> of.  Also, a human can certainly read the file format once he has
> taken the time to RTFM.  Human readability -- without knowing the file
> format -- is a "nice to have" which isn't high on my priority list.

I agree with all your other points, but would actually like to modulate this
one. While an XML format to some degree is more readable upfront, you will
still rely on documentation for the higher levels anyway, as they in no way is
encoded into the format. The basic format will be a little less cryptic than
the gEDA format, but higher level requirements cryptography will remain the
same, so you can never walk away from the RTFM factor. Never. So, to some
degree this aspect is as much a chimera as with the "finished parser", infact
for the same reason as these aspects is really application specific and not
format specific.

Other than that, I agree fully with you.

> These are just my opinions, of course.

Naturally. :)

> Finally, if you really, really want to play with gschem files in XML,
> you can grab a pair of .sch <-> XML utilities I wrote 4 years ago
> here:
> 
> http://www.brorson.com/gEDA/gschem/
> 
> If you really want XML schematic files, have fun with those little
> utilities!

Having XML capability through such a side utility may very well be a good
middle way. If you dress the bride up with DTD and documentation, it could be
usefull for those dying to toss their XML tools at the data, or indeed want to
interact with the data through XML. Maybe one should consider bringing it into
the GAF family.

PS. I beleive I was quite early out raising a voice against XML.

Cheers,
Magnus


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user