That business of the task element having a child element also named task is rather weird.

In addition, the JSON version of this would also be Quite Decent.

The "Add server-side support..." task is part of a larger task (or project) called "XProc Actions". I think that's the origin of the nesting.

And yes, in this particular case, JSON would also work. But I don't need another serialization for a subset of the full scope of documents I want to create. At least not outside the context of exchanging packets of data between JavaScript and some server process.

XML good. Turtle, N3... better. For example, John probably wouldn't find a <task> within a <task> weird if they were related by of:subTask or something. And you'd know what was going on with the idrefs.

I try to be an RDF fan, but I'm not sure I see how it would help here. The inner element could have simply been named subtask if that mattered, but I don't think it does.

How would RDF have made the ID/IDREF relationships any clearer?

The first thing I'd wonder, seeing data like that, would be whether the inner task element is always a reference or if sometimes it's a complete task element, e.g., if it's not referenced anywhere else. With RDF you wouldn't care, that decision is merely a whim of the serializer which will be dealt with by whatever library you use to read the serial form back in. It's of no more interest than whether the id attributes use single or double quotes.

For XML, in a way it would be better if the inner element was named subtask as that would clear up any confusion as to whether it's actually a reference to the supertask, for example. But the element wasn't so named, probably because XML, while mostly being fairly self-descriptive, leaves implicit the relationship between parent and child elements thereby encouraging designers to assume it's obvious.

Also giving the inner task element a different name makes it difficult to include tasks not referenced elsewhere in-line.

Similarly, the ID/IDREF relationship would be dealt with completely be the reader; you'd only need to think about the subtask relationship. Though id attributes are usually unique throughout the document that's only a convention; in the absence of an accessible DTD you might have to do some careful investigation to make sure that other element types can't have clashing ids, for example.

Yes, there are alternatives to XML... I'm fond of JSON, and seeing SQLite replace previous binary gorp under stuff like iPhoto makes me very happy.

But I still credit the XML movement with establishing the culture of open exchange behind all of these.

e.g. see slide 7 in my ALA midwinter 2000 talk.

Of course there are alternatives, they're just not as good. Yes, JSON is fine, I suppose for simple, perhaps even nested key value pairs. And SQLite is better than random binary goo, but mostly IMHO because there's a standard path to text.

I reverse engineered AddressBook's SQLite data and it was a minor PITA.

Sometimes there are good reasons to do something else, no doubt, but I'm still happiest when I find XML when I go looking for data.