fside - 7:58 pm on Feb 21, 2008 (gmt 0)

There's really not much to XML, itself. It's tags someone else might understand, and want you to use, closing tags or slashing empties, and namespaces. With HTML, you have to learn what all the tags do, and where they might go. XML is just - you name the tags. End of book.

As for XSLT, this is what helped draw people into XML. It's slow. But it works beautifully - with-the-grain as it were in creating HTML, also XML, text, even pdf (xsl-fo). It is useful to separate out the data collection from the page generation. But there's typically a lot of text. Text handling can be slow. XSLT tends to be slow.

In addition, XSLT gurus can, only some of them, seem to get on a purist jag where precise definitions only will do, needlessly complicating things for those who are using the namespace commands (elements) and arguments (attributes), properly. And XPath. What is the context is often the question during execution of an XSLT script. What IS position() #1? and so on.

But it's okay that you have a choose and else and otherwise for every if/else conditional. But that verbosity becomes a problem when data is transmitted, lots of it. Proprietary formats were likely pretty efficient, without a lot of duplication. So first, not in elements, but in attributes. You have to use the attribute name every time within an element. And if attributes in the source and transmitted as elements in the XML, you still have the duplication. XML is very verbose in that way. JSON does make more sense, and solves the universality problem. Like XML, it's not some proprietary format.

I think if it hadn't been for M$ adoption of Xpath/XSLT, and for providing its xml/xslt v1 program modules, that XML would have been another of these that didn't take, like the latest from ECMA, perhaps we'll see what comes in as the 'new' HTML.