Several people have commented on my most recent post arguing that what is really required is more fundamental than Ajax and needs to be XML based. Despite having been part of XML pretty much since the beginning (late 96) I have a very pragmatic point of view about this. Engineers should use the best tool for the job. For example, sometimes the best way to send data from the server to a running page isn’t XML. It is a Javascript fragment that when “eval’ed” on the client turns into a set of js arrays or values which can then be used within the page. This can be faster and easier to program. If so, why not use it? More generally, I actually agree that Ajax is somewhat transitional, as I hinted at the end of my last post. It makes pages richer and more interactive which is a good thing when appropriate (again the right tool for the job), but it doesn’t solve the issue of creating content for mobile devices or many other issues. That being said, this idea that XML is the “answer” arouses my skepticism. I think it can be a useful tool and it can be a religious mistake. For example, in the early days, Xpaths weren’t expressed as they are now, e.g. as expressions. Instead they were expressed as big chunks of XML, a sort of XML infix parse tree for the expression. It was awful and we fixed it. Similarly, XML turns out to be a very cumbersome way to encode procedural logic compared to, say, script. What is really useful about XML is that the parsing/tokenization comes for free and that it can represent a very rich set of data models and it is relatively self-describing and that, at this point, it is standard. So when the problem calls for a tool which requires sharing data between applications or encoding state of an application (e.g. the new Office announcements from Microsoft) it seems reasonable. But when describing the procedural logic within an application or even the expressions, in my experience, it usually is not.
One clear limitation of XML is that there isn’t an easy way to update it. If you already have some XML and want to alter it in some way, there is simply no standard right now for doing this and the DOM code is usally both hideous to write and relatively fragile since there are no guaranteed ID’s on elements or checksums. Another obvious limitation is moving binary data about. One of the XML founders tells a hair-raising story of a company telling him how they plan to move video around by encoding it and including it in the XML itself. Because of all this, I’ve recently been spending a lot more time working with ATOM and RSS 2.0. These are XML, but they are more. They have the idea of sets which means that one can understand how to insert or replace items and ATOM has a protocol for this. It also means that some very low tech ways can be described to get subsets out of them. They support the idea of LastUpdated and ID so that replacing an item within the document can make sense. And they have explicit and very sensible ways to point to binary data which describes where it is, what type it is, and how big it is and then leaves it to the client to use normal ways to subsequently fetch in this data.
Anyway, I don’t mean to argue to strongly with the thoughtful comments on the previous post, but to caution that this is all engineering, not religion, and pragmatism should rule.
Adam Bosworth's Weblog 