I am underwhelmed by this article, and not just because it's dated. (DTDs?) Most of the problems the author attributes to XML are in fact problems associated with the application domain that he's trying to apply XML to. It's hard to get the pharmaceutical industry to define and adopt a common data model? That has *nothing to do* with XML.
Similarly, the complaint that XML isn't inherently readable, and that you have to write XSLT to convert it to HTML for presentation, is muddle-headed. What format for representing structured data in a transportable form *would* be human-readable? CSV? JSON?
The complaint that XML is hierarchical is also bogus. It's perfectly straightforward to represent data relationally in an XML document, if you have to. It's just that for most uses of XML, where an XML document is a concise and transportable bag of information that can be parsed into an object model, representing relationships hierarchically is easier. Since object models represent hierarchies, and they represent them because the hierarchies actually exist in the real world that the objects are modeling, a far more apposite complaint would be that relational databases do a poor job of modeling hierarchies. If you're going to get into this at all, which you shouldn't.
This article is primarily complaining about the hardness of certain problems and then castigating XML for not magically solving them.
A *good* article about XML would have addressed the simple question that kagemaru asked:
> In most of cases, they will state together what will be the
> XML structure to have their program running well : So, what
> is the difference with a csv file ?
Well, what *are* the differences between representing data in XML instead of CSV? Here's a couple off the top of my head:
- XML provides a good way of representing hierarchies. CSV doesn't.
- XML documents can be reliably parsed into an object model that can be programmatically manipulated; this object model is implemented in a standard way on many different platforms. Not so for CSV.
- A powerful (if daunting to learn) platform-independent language for searching through XML-based object models exists. Not so for CSV.
- Standard, platform-independent tools for defining the format and organization of XML doucuments and validating that a given document contains what it's supposed to contain exist. Not so for CSV.
- Standard, platform-independent (are you detecting a theme?) tools for transforming data in XML documents into other formats (in particular, into HTML, for presentation) exist. Not so for CSV.
- There's a consistent way of programmatically verifying that the data in an XML document hasn't been corrupted or truncated in transit. Not so for CSV.
- XML documents tell you their character encoding. CSV documents don't.
Now XML has plenty of drawbacks. Above all, it's not terse. This drives people crazy: all those redundant closing tags and repeated attribute tags. That's part of the cost that you pay for representing your data in a transportable form that can be programmatically validated and transformed by platform-independent tools. If you don't need those things, you shouldn't be using XML.
Also, namespaces and CDATA are hard to understand. I'd contend that if you're using XML and you don't understand namespaces, you probably don't really understand what XML is yet and you probably shouldn't be using it.
Finally, since any clown can write an XML document, lots of clowns do. It's a general-purpose format for representing data, and as such, it lets you make all kinds of stupid mistakes if you don't know what you're doing. Pick up just about any "introducing XML" book and you'll find an inadvertent compendium of worst practices.
XML is a technology that addresses a lot of hard problems better than any other technology we have. If you don't need those problems solved (as the author of this article clearly doesn't think he does), you shouldn't be using XML.