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:

	* XML can be made line-oriented and so is amenable to merging SCM tools.
	* XML abstracts presentation ontologies from logical ontologies, so allows presentation-tool manufacturers to compete on a level playing field.
	* XML permits multiple data ontologies and data versions to be aggregated in the same data file without prior agreement between the users.
	* XML enforces consistent name-space semantics so that data can be adorned without interference between users. For example, ZopeApplicationServer's super-nifty ZPT/TAL/METAL that permits graphic designers, programmers, and ontologists to all mess with the same file without tripping over each others' feet.
	* XML is NonPermutationDependent, so encourages programmers to MakeParameterizationPossible, in theory '''if not common practice''' enabling software to interoperate in new ways without recompilation.
	* Finally, yes, there's an outside chance that XML actually encourages programmers to share encoding standards. What we're seeing at present in this context is a PatternOfBabel ... but maybe one day we'll figure out a way to make adequate tools to navigate, reconcile, and RefactorXml.
* The repeating "named ender" approach (<foo...>...</foo>) seems to be more robust to editing mistakes (easier to re-string) and improves readability for many people. (Similar arguments at TheRightWayToDoWordyBlocks.)
* Power-users or "half programmers" can learn and relate to it fairly easily, far more so than typical application code. This can off-load some of the programmer's work-load for semi-standard or frequent needs. This is because of the uniform syntax and its mostly declarative (attribute-based) nature.
* People in general mentally relate to visual nesting better than reference (ID) based associations. In ID-based approaches, nested associations are not visually apparent. (And XML can still handle non-hierarchical relationships when needed.)

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.

* Tables are "hierarchical"? Then again XML is not really hierarchical either if you count named references. Syntactically it is a tree, but representationally it is not necessarily. Or is this meant as a TopMind imitation for amusement purposes?

** Of course you can make a hierarchy of tables but you are also free to represent non-hierarchies using the same technology, infinitely increasing your flexibility with no added complexity.

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