SOAP of the evening, beau…tiful SOAP

There are simple ways to do things on the web, and there are Simple ways. Jonathan Robie, a long-time member of XML-DEV found this…

From: Jonathan Robie
To: “xml- >> ‘XML Developers List'”
Subject: [xml-dev] The S stands for Simple
I thought this was pretty funny:

Read it, even if you aren’t a techie. Yes, it’s hilarious, but it’s also tragic and true. What’s it about?
The Web needs standardized ways of doing things. Remember the browser wars when Netscape and Microsoft fought each other to a standstill? “Best viewed in XYZ version 1.2.3”. With the advent of XML a whole new technology was generated. Rightly or wrongly XML has been adopted as the lingua franca of middleware and the infrastructure of the Web. When it’s used well, it’s great. I’ve had the great privilege to be part of that community and been involved in some of the most exciting virtual communities of all time. First there was XML, led by Jon Bosak, supported by Tim Bray, James Clark, Norbert Mikola – I’ve documented it on on XML-DEV. Then XSLT – a good design (if rather purist in its insistence on being a declarative language and devoid of useful procedural functions – e.g. no storage!). And then SAX – to me the epitome of the collaborative Web community. After my nagging on XML-DEV, David Megginson took control and directed, orchestrated the contributions from ca 100 list members. The full story is told here. David finishes:

Thank you to the following people for contributing to the initial discussion about the design of SAX. The current proposal contains many of their ideas and suggestions, though it does not match exactly what any one person wanted.

SAX was not design-by-committee – it was design-by-BDFL-led-meritocracy. It took a month. One month. It’s on every modern computer on the planet. It’s simple, it works and it does exactly what it says on the tin.
And then there are the horrors… Overdesigned, incomprehensible, unusable, committee-driven. And in my nightmare dreams I assume that they are deliberately designed badly so that IT companies can sell training and installation into customers. At one stage I thought it was simply that I was an inferior being and could not aspire to the rigours of software engineering. I assumed that the complexity and impenetrability were necessary for robustness. That if I didn’t use them my code would fail in horrible places beyond my control.
One of the worst horrors is the W3C DOM. I have wasted a year of my life on this disgrace. An object-based protocol which deliberately forbids subclassing???! Where the return value of a missing attribute is undefined. Where there are multiple ways of doing most things. I wrestled, and I thought it was me. I wrote a complete wrapper for this monster to try to get Xerces to work. (I will expound my extraterrestrial theory of Xerces later…). And then – about 2 years ago I discovered XOM. A DOM I could understand and use. A simple DOM. The only problem was it isn’t a standard. And I’d like to use standards for CML. But it’s author, Elliotte Rusty Harold, wrote so eloquently about why the W3C DOM is so awful that I realised we were right and the W3C was wrong. As simple as that.
So many of us are waking up (or fully awake) to the fact that many, if not most, fomral specs are over engineered. The world is splitting into two camps, those that favour fully engineered specs and those that like lightweight – even ultra-lightweight approaches. Here’s a table of heavy and light (my assignment).

Again we wasted an elapsed year with WDSL, we’re taking it all down and redoing it in a RESTful manner.
So, like Humpty, I’ve had enough – ‘I meant by “impenetrability” that we’ve had enough of that subject, and it would be just as well if you’d mention what you mean to do next, as I suppose you don’t mean to stop here all the rest of your life.’