CadSoft EAGLE development team developing XML format for schematic, layout and parts libraries!

Personally I don't think that is a good idea. Xml itself introduces ambiguitiy, as does text. It is also language based (and large, slow to parse and all the regular issues). I would way rather they open the binary formats if they haven't already. The existing text formats (like the spice format) work fine and are way more readable than xml as is.

I understand I may be a minority in this view : ).

it doesnt take longer to parse text than to parse binary.  XML is much less ambiguous than text. also, XML -is- text

Well seeing as binary can just be a cast I'd say it is slower - I agree it doesn't have to be 'too slow', but it often ends up that way.

XML is more ambigous than a good documented text format imo - eg like spice, PS etc. For example you have tags vs attributes, or unicode vs ascii, etc. That can be doc'd, but as a user you have to remember if it is one, the other, or both. And that is 'if' it is doc'd properly. That said, it is binary now, not text - I think they use text for some of the config stuff (like hotkeys iirc) though, which is why I mentioned it...

Most tools for xml formats have problems accepting files that are 'legal' as far as the schema once the format becomes a bit large. I've had lots of issues with that in both SVG and XAML, and of course HTML seems to be hard for everyone to get right on the edges (even harder for editors). With a binary format it tends to blow up or work, which imo is more desirable.

As far as viewing, you can view it in Eagle. I think the format is mostly interesting to those who want to tool against it.

The one major plus of a text format is version control. You could have a tool that converts to and from open binary <> test/xml for that, but I agree that is less optimal. So one large point for text formats there : ).

Ah well, I'll take open xml is over closed binary any day, so I'm with you for sure... Just feel 'open binary' is never given fair consideration. Ironically I think its main strength is portability - not of the parser tool, but of the exact meaning intended.

Well, I for one will be very glad to see an XML file format implemented.  Back in my Cadence days I wrote a Java-based netlist parser app to convert between languages (mostly SPICE, Spectre, Verilog-AMS and VHDL-AMS) using XML as an intermediary format and XSL Transforms to interact with the source and generate the destination formats.

Aside: I hate SPICE precisely because it is totally ambiguous, poorly documented and incompatible between all the permutations and combinations out there between EDA platforms.  At least the hierarchical nature of properly formatted XML is parsable independent of the content or even a formally defined schema.

Aside 2: IMHO, if you have to use regular expressions to get at the atomic structures contained in an "XML" format like you do in SVG, it's not proper XML.  Things like coordinates should be accessible as discrete XML elements or attributes accessible through simple XSLT code.

If size is a concern (which it was when dealing with GB-size netlists) you can use a generic zip algorithm to compress the text and serialize the I/O.  As a bonus you get encryption, authentication, error correction and all that other good serialization infrastructure for free.  It'll add a layer of I/O complexity for revision control, but if the RC supports generic zip-diffs, all text formats will benefit, not just XML.  You also get ascii vs unicode vs localization controls for free with most XML-based APIs, independent of whether the tools (don't) have it.

Aside 3: Avoid the DOM-style XML readers that suck in the whole XML content before you can do anything with the content.  You're much better off using a SAX approach to create your own (sparse) data structures on the fly, with the added benefit that when data's corrupt you can more easily identify and work around where things are broken in the stream.

Well, I for one will be very glad to see an XML file format implemented.  Back in my Cadence days I wrote a Java-based netlist parser app to convert between languages (mostly SPICE, Spectre, Verilog-AMS and VHDL-AMS) using XML as an intermediary format and XSL Transforms to interact with the source and generate the destination formats.

Aside: I hate SPICE precisely because it is totally ambiguous, poorly documented and incompatible between all the permutations and combinations out there between EDA platforms.  At least the hierarchical nature of properly formatted XML is parsable independent of the content or even a formally defined schema.

Aside 2: IMHO, if you have to use regular expressions to get at the atomic structures contained in an "XML" format like you do in SVG, it's not proper XML.  Things like coordinates should be accessible as discrete XML elements or attributes accessible through simple XSLT code.

If size is a concern (which it was when dealing with GB-size netlists) you can use a generic zip algorithm to compress the text and serialize the I/O.  As a bonus you get encryption, authentication, error correction and all that other good serialization infrastructure for free.  It'll add a layer of I/O complexity for revision control, but if the RC supports generic zip-diffs, all text formats will benefit, not just XML.  You also get ascii vs unicode vs localization controls for free with most XML-based APIs, independent of whether the tools (don't) have it.

Aside 3: Avoid the DOM-style XML readers that suck in the whole XML content before you can do anything with the content.  You're much better off using a SAX approach to create your own (sparse) data structures on the fly, with the added benefit that when data's corrupt you can more easily identify and work around where things are broken in the stream.