3 ms·
Reason XML went out of favor I think has to do with decision to focus more on efficient parsing by machine and less on readability and simplicity. There was a c
by dragonsh 6y ago
Reason XML went out of favor I think has to do with decision to focus more on efficient parsing by machine and less on readability and simplicity. There was a competition between XSD (XML Schema Definition) [0] and RelxNG [1] for defining the structure of XML. Personally I preferred RelaxNG, but at that time Microsoft and many big players converged on XSD. So XSD won but XML is out of fashion.
I wrote a XML encoder and decoder with XSD for an EDI application handling 2-3GB files in C++ using MSXML and it was very slow, improved the speed using stream parser, but still slow. Later on using libxml rewrote the parser in C with RelaxNG and the processing time reduced from hours to seconds on the same hardware. At that time as RelaxNG lost in spite of having elegant structure compared to XSD. I had a lot of arguments with my friend that RelaxNG will win because it's readable, simple and support every use case supported by XSD. But due to support from many vendors especially Microsoft (as most enterprises were using microsoft) an inferior solution like XSD won, because Microsoft focused more on computer consumption of format instead of human. So although XSD can be read no one could understand it. This is one of the reason JSON, YAML and TOML have picked up because they offer the readability and parsing at the same time. Hopefully people can understand it this time and do not destroy JSON with complex JSON Schema definitions.
Take a look at both:
Relax NG example in compact syntax:
element book {
element page { text }+
}
Relax NG exmaple in non compact syntax:
<element name="book" xmlns="http://relaxng.org/ns/structure/1.0">
<oneOrMore>
<element name="page">
<text/>
</element>
</oneOrMore>
</element>
-------------
XSD example:
<xs:element name="book">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="page" type="xs:string" maxOccurs="unbounded"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
[0] https://www.w3.org/TR/2008/REC-xml-20081126/ https://www.w3.org/TR/2008/REC-xml-20081126/
[1] https://relaxng.org/ https://relaxng.org/
- hnick 6y agoThere's also the question of using a SAX or DOM based parser. More than once, I've had to update a program using 32-bit perl from DOM (simple, fast) to SAX (slower but more control) as documents grew and the scripts crashed due to Out of Memory errors. Using SAX gave us event based handling to ignore certain nodes, or cache them to disk in another format as they got too big, and other fun stuff. Rule of thumb was to multiply the document file size by 10 to get the memory footprint with a DOM approach, because of all the objects, relationships, and metadata that has to be stored for everything. One individual records got up above 100MB on disk we were in the danger zone. Whereas JSON just loads into hashes and arrays and tends to not pose similar problems.
- tannhaeuser 6y agoThere's a bit more to it, though. XSD keeps backward-compat with XML DTDs, and XML DTDs, in turn, keep compatibility with full SGML DTDs (XML being specified as an SGML subset). Now DTDs are usually required in SGML unless you're using XML-style canonical markup without omitted tags and attribute names. What makes them required in regular SGML is that element declarations carry tag omission indicators instructing an SGML parser to infer contextually required tags. Tag inference in SGML is deterministic; that is, the parser only considers start-element tags that are required and end-element tags for definitely completed content models at the context position. Also, in the presence of tag omission, an SGML DTD is required even for parsing (for example, HTML cannot be parsed using generic XML rules but needs element-specific content and tag omission rules). So the design rationale for XSDs to retain backward-compat (what's responsible for XSD's "unique particle attribution" constraint) leads to a different result compared to RNG. By contrast, RNG is a "clean restart" working only for canonical XML-style markup, and is always optional (and only used for "validation"). One could argue XML took away what makes SGML a true authoring format to result in only a canonical delivery format, but these were willful design choices when XML was subset from SGML. Now as to whether XSD's or RNG's format for grammars are prettier is a moot point. IMO there was never a reason for using an alternate XML syntax for SGML/XML DTD regular expressions/regular content models. Eg compare your example with it's equivalent (simple, compact) traditional element declaration: <!element book - - page+>
- bawolff 6y ago> less on readability and simplicity I strongly disagree. The reason XML went out of style is because it in practise was a convoluted complex mess that was difficult for both humans and computers to read.
- arethuza 6y agoI like XML (though rarely use it these days) and JSON but I would have to say that the worst XML I've seen was far far worse than the worst JSON.