XML Fallacies Revealed
While catching up on my reading of the blogsphere, I noticed a common thread. After years of proclaiming the virtues of XML, the technorati now has hit a dose of reality.
Martin Fowler blogs (or should I say blikis) the insurmountable problems of XSLT:
- XML makes a lousy syntax for a programming language. There's way too much noise in there and as a result you can't see the program.
- XSLT makes calling subroutines so painful that you are seriously discouraged from using them, which encourages duplicate code.
- XSLT handles simple tasks well, but is baroque when it comes to more complicated things. Indeed some are impossible and you have to jump out into another language anyway.
- Ruby gives me a clean, OO language with clear syntax and a kick-ass XML library.(Python may well be just as good, I haven't tried it.)
- I can mix template style code with transformer style code.
I think this may raise some real questions about XSLT. There's still much I like about the power of XSLT, but I hate the syntax and the walls you keep running into.
XSLT's 'brick walls' are actually made of ten foot thick, five mile high, sheets of titanium alloy. When you hit one you stay hit.
Couldn't have said it better myself!
Simon St. Laurent writes about the mistake that is XML Schema:
Today, the XML landscape is far more complex, with specifications good and bad littering the computing world. One of the most bloated, W3C XML Schema, has dominated the tools world despite interoperability and complexity issues. Thanks in large part to early support from vendors, this collection of issues masquerading as a schema language continues to dominate the XML world - and in my opinion, makes the cost of using XML much higher for both vocabulary creators and consumers of those vocabularies. ...
Stop pretending that these things have object hierarchies, and stop hacking around the conflicts between object hierarchies and document realities with broken tools like substitution groups and keys. Focus on the documents themselves and the structures you'd like to have in those documents, and there's a chance you'll produce documents that are a pleasure, rather than a burden, to work with. You can build schemas using this understanding of documents with RELAX NG, a schema language that describes document structures, not type structures abstracted on top of document structures
I've always was wary of the unnecessary complexity of XML schema, fortunately Simon makes clear the one of root causes of the complexity. It's time that the industry accept reality, it's a first step to exorcising one's demons. However, leave it to Victoria Livshitz to summarizes the sad state of affairs:
The world has gone crazy with XML and then web services; SOAP and UDDI are getting enormous attention, and, yet, from a software engineering standpoint, they seem to me a setback rather then a step forward. We now have a generation of young programmers who think of software in terms of square brackets. An enormous mess of XML documents that are now being created by enterprises at an alarming rate will be haunting our industry for decades. With all that excitement, no one seems to have the slightest interest in basic computer science.
Paradoxically, Uche Ogbuji in "Objects. Encapsulation. XML?" seems to hint that the lessons we learn from XML will lead us to a "post-OO sensibility". He coins "dynamic, declarative and data-driven (D4)" serendipitously that's a subset of this loosely coupled taxonomy.
The strangest thing of all is this, despite the fundamentally flawed ideas behind XML and Web Services, both technologies has made people really think about the issues of interoperability and programming in the large. This is leading to some very interesting approaches that one could never have risen within the a pure OO mindset.
Last modified 2004-02-26 07:44 AM