Benefits Of Xml

No, it's not actually human-readable. Well, maybe very, very tiny datasets are, but anyone who's ever attempted to pore through any XML dataset of size realizes that the stuff makes a BigBallOfMud (XmlSucks viewpoint). So what are the BenefitsOfXml? Here's just the obvious ones:

Well, that's what I hoped a couple of years ago. But with schemas there is no permutation independence so you can't aggregate different or new ontologies without screwing up. Plus, since there are still permutation-independent variations, different XML files can contain the same data, so your line-oriented SCM won't work. Abstracting presentation away from logic might be great if you could RefactorXml ... and if schema writers would stick to that. But you can't and they don't. Lastly there are umpty ump different ways to play name-space games in HTMLish tools - including DTML for you ZPT freaks if you just encapsulate your HTML correctly - so no advantage there either.

It seems that all these supposed BenefitsOfXml are illusions. Worse, XML suffers all the obvious problems of hierarchical data. It's self documenting the same way COBOL is self-documenting. It's really MuttonDressedAsLamb, a way to increase the number of translation layers between database and presentation and so make systems more fragile and semantics more implicit.

XML is dead. Long live YAML (YamlAintMarkupLanguage). --PeterMerel.


Among the hardest things to get right in designing any text file format are issues of quoting, whitespace and other low-level syntax details. Custom file formats often suffer from slightly broken syntax that doesn't quite match other similar formats. Using a standard format such as XML, which is verifiable and parsed by a standard library, eliminates most of these issues. -- Keith Packard

The downside is if the parser somehow implements it wrong (from either sender or receiver), it may be harder to tweak than say comma-delited. Reverse engineering or rolling-your-own comma-delimited parsing is much simpler than XML. However, I imagine that over time the XML parsers/generators will get more reliable.


The most significant benefit of XML I've seen is that receivers can ignore unexpected elements. This makes upgrading simpler since the sender can add data before the receiver can process it. --EricHodges

It doesn't take XML to do that. You can do it with plain text, or with binary files, both of which has been done long before XML. There are even standards for formatting and identifying data chunks in binary files so applications can skip unknown stuff added by another one (like Electronic Art's InterchangeFileFormat?, and its little-endian counterpart, ReverseInterchangeFileFormat?) -- Anonymous

Correct. But XML has been introduced in situations that previously used raw serialized structures. And I'm grasping for something good to say about XML. -- EH


XML is a human-readable and human-editable format for hierarchal data with readily available parsers and editing tools. Plus, most semi-technical people have some familiarity with it. For those reasons, it's the most practical syntax I've found for configuration files, though property files also work.


Rewrite the above to say: Tables are a human-readable and human-editable format for hierarchal data with readily available parsers and editing tools. Plus, most semi-technical people have some familiarity with it. For those reasons, it's the most practical syntax I've found for configuration files, though property files also work.

Then add: In addition, it maintains readability for millions of records, is instantly queryable, importable, exportable, and has a host of other features that XML will never have because XmlSucks
The biggest benefit of Xml is that it's a reinvented wheel in the form of a square. This allows developers and tool-developers to reinvent square wheel tools, square wheel syntax, square wheel specifications, form square wheel committees, integrate square wheels to machines, and form new square wheel industries to address its own flaws of the design, which were known ages ago.
XML is good for mixing standardized data when space is less of an issue. Using XML just to use XML is not always worthwhile. The strongest aspects of XML are in its WWW use- being able to mix HTML (_maybe_ MathML) and SVG in a way easily bridgable by script can be useful, but don't expect your browser to understand Pet Store Inventory Markup Language beyond styling it with XSLT and CSS.

Every single 'benefit' on this entire page is a subset of relational benefits and worse in every single way. Table schemas > Xml shemas. Table querying > Xml querying. Table performance > Xml performance. Table ubiquity > Xml ubiquity. Table storage space > Xml storage space. Table readability > Xml readability. Table tool power > Xml tool power. And SQL Syntax is infinitely easier than XPath. I could go on and on.

Note that XML and relational are not necessarily competitors. Also, there is currently no accepted standard for transferring multi-table relational data in a text-codified way (although this wiki has offered suggestions). The closest is ODBC, but it's not currently text-based.

You can generate SQL Scripts to export/import tables and schemas in Oracle, SQL Server, etc (or you can use RedGate?, even better).

True, but I'd personally rather see something like FlirtDataTextFormat. Having verbs like INSERT, UPDATE, and DELETE in a data exchange format makes me a bit noivous. It's also a pain to parse.
HTML caught on because a wide variety of people are able to grok it fairly quickly. I've seen many non-programmers pick it up fairly quickly. Thus, it's been road tested in that regard. The alternatives have not. Hell, even many programmers often find EssExpressions and their cousins difficult to read. Sometimes redundancy improves readability, it seems (at least for enough people, realizing everyone's WetWare is different).
CategoryXml

EditText of this page (last edited October 24, 2013) or FindPage with title or text search