Slashdot Mirror
Celebrate the XML Decade
IdaAshley writes "IBM Systems Journal recently published an issue dedicated to XML's 10th anniversary. Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML. Learn why XML has been successful, and what it would take for XML to continue its success."
Strange that an article celebrating XML's anniversary would neglect to mention XML's creator. I wonder if the fact he works for a competitor has anything to do with it...
All we can celebrate is a decade of bloat. For hard drive manufacturers and bandwidth providers, this has been a great development. But for those of us who have to deal with systems that use XML, we often wish that they had chosen a far more compact representation.
S-expressions, of the sort used in Common Lisp and Scheme, would have been a good alternative. They're simple, use a minimal number of characters, and are very easy to parse. Hell, most Comp Sci grads have written at least once such parser during their education.
The worst use has perhaps been with AJAX. Had AJAX been based around data passed as sexprs rather than as XML, it would consume much less bandwidth, and could be handled far quicker on the server side. Unfortunately, a poor technical decision was made to use XML. And so we get to hear all about the performance problems people experience with AJAX systems.
"IMO a C-like syntax using nested {}s would've been better."
JSON?
Who doesn't like free music?
Actually, that would be 1040 -- 'X' (10) before 'M' (1000) = 990 + 'L' (50) = 1040
HL7 is a "standard" for moving patient information from system to system. I call it a "standard" because the 1.x and 2.x versions were largely "advisory", with more MAY than MUST, with a huge amount of wiggle room... I've worked on 4 information exchange projects now, and all of them started from scratch because none of their HL7 "specs" are compatible.
Supposedly the new version 3 standard (which uses the "modeling approach") will be much more firm with the implementors, which will hopefully mean that every now and then one implementation will actually be compatible with another implementation. I've looked over their "models" and they've modelled a lot of the business use-case stuff for patient data, but not a lot of the actual data itself. Hopefully when it's done, it'll come out a bit better baked than previous versions.
And if anyone's under any illusion that JSON isn't try to reimplement XML I'd like to introduce you to JsonT... JSON Transformations.
> The error message does not help people all that much
:-)
One case where it helps most is when an incorrect start tag was applied; with the empty end tag this could not be detected, and it turned out to be more comman than one might expect. You're right that the error messages often aren't good, but did you ever try debugging a large SGML document with OMITTAG and SHORTREF in use? The error message was almost always "characters found after end of document" because the required strategy by SGML (in one of the most common error situations) was to close elements until you got a match, so the parser typically closed elements all the way up the tree to the document element, and then gave up.
We were bound, at the time, to strict SGML compatibility; perhaps if we had known XML would succeed we could have made more changes, but then we would have strayed further from the well-trodden path of implementation experience.
As to comments for attributes, I agree with you; we lost them, though because we needed a language simple enough it could be processed e.g. with Perl. We didn't dare dream that Perl would support XML natively!
I agree with you that structured tools should generally be used. The redundancy and simplicity help computer-generated XML, and help to detect, say, missing portions of documents. If xml-rpc is scary, s-expr rpc is even scarier!
Liam
Live barefoot!
free engravings/woodcuts