Dave Thomas says: People think, "Once I've got my data in XML that's all I've got to do. I've now got self-describing data," but the reality is they don't. They're just assuming that the tags that are in there somehow give people all the information they need to be able to deal with the data.

One of the most useful parts of any XML file is the comments that are used to help explain things. There are faculties for making XML more human-readable, people simply have to make use of them.

When I hear someone say "XML is self-describing", I don't take that to mean that they think an XML document all by itself can tell you everything you need to know about it. My interpretation of this is that one doesn't necessarily have to draw upon an outside source to decode the meanings of the various tags. Certainly, some systems will use XML in ways that are only slightly more readable than binary formats, in which case, yes you do need to refer to an outside source to understand the file. And there are ways to handle more complex scenarios where you need a DTD or XSD or some kind of data dictionary to understand what is going on in the XML document. But in many cases, the XML document itself can do all of the work.

A big advantage of using XML is the fact that it's pretty widely-known. Using org.apache.commons.digester, I was able to give the users of a simple command-line tool I wrote a means of configuring the tool from a simple XML file (when I say simple, I'm talking about 5 or 6 elements). I provided an extensively commented sample XML file that could be used as a template for later configurations. If I need to extend the features of this file, I can do so easily without fear that my users will have to learn new, unfamiliar syntax for the configuration file (they will only need to learn any new elements or attributes that are added), as long as I remain within the XML standard. And chances are good that I'll be able to find a parser, perhaps one as easy to use as Digester, that can accommodate the changes, so I won't have to roll my own.

In short, I think a large degree of the responsibility for ensuring that XML documents are human-readable is with the author, or the author of the tool that will generate the documents. It's not the XML format itself that has an inherent problem with being human-readable.

yes... some times I will think some XML is too complicate to handle, like the file format of openoffice.

I will think that some content package format, like SCORM (http://www.adlnet.org), only store the table of content and the pointer to the real content in the XML, then the package reader get the individual page information according to the pointer. I wonder if it is the better approach of storing big XML?

It's not always immediately obvious what a new technology really adds. I think TimBL (maybe Fielding?) once said of the web (paraphrasing) HTML isn't so great, HTTP isn't so great, but a universal address space (i.e. URI) turns out to be very useful.

In the case of XML, angle brackets and attributes may not be so great, and sure, people can do some pretty stupid stuff, but the advancement of Unicode as a standard text encoding is, IMHO, a Good Thing.

Just a quick pointer for the programmers out there: if you're interested in using plain text files as a way to generate Docbook XML files (which has numerous advantages, considering the growing variety of tools for it, but IMHO is a pain in the neck to edit "by hand"), check out the docutils plaintext converter (written in Python):

http://docutils.sourceforge.net

With this tool, I can write using plaintext files with almost no markup (or very very little, in any case), then easily generate HTML pages or LaTeX documents, and eventually Docbook XML (there is an unfinished-but-working implementation of conversion to Docbook).

FWIW,
Word 1 was pretty much just plain text.

Loud cheers for the statement that XML is an ill-fit for user-input.
That's exactly what bothered me in the recent efforts at rebuilding aspectj in open source XML format.
(See Cedric Beust's weblog or Rickard ?berg's).
Somehow they seem to think it's the other way round.
Now my own opinion is validated by the authorities. My superego is sighs with satisfaction. :-)

But what I'd like to ask Dave & Andy: is writing your own grammar using javacc, lexx/yacc or whatever the only alternative they think of when they say 'xml sucks'?
Because a lot of times I think XML with it's metadata validation (XSD's) is better then the alternative which would be at most customersites I visit no validation or validation interpersed with parsing code.

Ofcourse XML is now mainstream so there's more newsvalue in criticising it, but unless Dave & Andy can come up with some other alternative than using lexx/yacc I think XML is most of the times the least bad alternative.

And Sun's machine generated XML files seem to have been a first try at declaring information (deployment information, transaction information,...) that is not in the same plane as the code. And looking back I think we decide that it has these drawbacks they mentioned and that metadata attributes as in .Net and JSR 175 & 182 offer a much better design.

groetjes,
Joost

> Dave Thomas says, "XML is useful in appropriate contexts,
> but it is being grossly abused in most of the ways it is
> being used today."

The problem with XML is that it's the round peg that's being shoved into holes of every shape.

We're better off today because we have XML; at the small end of the spectrum, I'd rather parse someone's tags rather than deal with writing regexes or yacc grammars each and every time someone has worthwhile data/metadata I want to process. And let's not forget that not every programmer can switch hats to write bug-free regular expressions or yacc grammars. If they can express their data with a small XML vocabulary, I'm not going to be held hostage by their buggy grammar or my buggy regex; we can agree to use an XML parser as a foundation and reliably interchange data with each other.

Of course there are instances where XML is misused, abused or simply a bad choice. Ant build files are one example. Apple's plist format is another. At the same time, there are text-based grammars that are worse -- Makefile syntax (in all its many splendored dialects), *roff or *TeX for example -- so shunning XML in favor of a simpler text-based format is not a panacea.

The crux of the problem we are facing is that programmers do not create easily parsed, simple data formats easily (complex formats and buggy parsers are much easier to create). The issues with abusing XML are the same ones we find with underspecifying a text-based grammar, or creating an overly complex text-based grammar. Swinging back from XML to text/yacc isn't a magic bullet, and won't solve any problems in and of itself.

I've been following this critism of Ant for sometime now. I find it ironic that the point of illegibility made against it contradicts one of the reasons I have suggested folks use it. How it in effect becomes a document to the build process and I don't have to go to someone in a SCM group to understand how the application is built. Where is the problem? Being dependent on the java program that consumes it?

I agree. I've heard this critism of Ant for sometime now. I find it ironic that the point of illegibility made against it contradicts one of the reasons I have suggested folks use it. How it in effect becomes a document to the build process and I don't have to go to someone in a SCM group to understand how the application is built. Where is the problem? Being dependent on the java program that consumes it?