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. In short, the reasons against XML are: * We already have a fixed, well documented, ASCII file format already. It's over 8 years old, well used and well tested. * We already have a parser for our file format already. Its lightweight & thoroughly debugged. * There are lots of legacy designs using the file format out there already. People would scream if we switched file formats since their old designs would become obsolete. And supporting two file formats -- old and new -- would be a major PITA. * As somebody already observed, XML files are bloated pigs. The gEDA file format is light & well adapted to its purpose. * One purported benefit for XML files is that there are lots of open-source parsers for them available, making integration into libgeda trivial. That's the theory, but in reality the job of a parser is to parse the input, and then stick it into datastructures suitable for use with the rest of gschem's code. An open-source parser does about 1/3 of the job we need (i.e. reading the file & creating some kind of parse tree). The rest of the job involves putting the stuff in the parse tree into libgeda's data structures. That's lots of work. Therefore, the purported advantage of the freely-available XML parser is a chimera. Yes, it may be of interest for a new program written from the ground up, but not for an existing program like gEDA. * Our developer time is better used on implementing new features like backannotation. Using developer time on porting our file format to XML is a sideways move which doesn't provide the end user any more utility, but soaks up valuable developer time. * 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. These are just my opinions, of course. 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! Stuart _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user