For some reason I don’t really understand, Don Box’s appeal for Pragmatics has had exactly the opposite effect from what I think was intended- more thunder from the RESTifarian pulpits, not an consensus to do the simplest thing that actually works for the different types of problems we face.
After working with XSD for about three years, I came to the conclusion that XSD has held back the proliferation and advancement of XML technologies by about two or three years. The lack of adoption of web services technologies like SOAP and WSDL on the world wide web is primarily due to the complexity of XSD.
These problems with XSD apply whether the schema describes resources or services, nouns or verbs, lightweight AJAX payloads or heavyweight WS-* service descriptions. For any non-trivial software development problem, the information in those XML whatever-they-are’s is going to have to get processed by actual software (usually written in a typed OO language). All those nasty details — about null values, type system impedance mismatches, assumptions about cardinality, schema versioning and evolution, ad infinitum — don’t magically go away just because you think of your information as a resource rather than a service and manipulate it with 4 verbs rather than with more complex service contracts. The slightly snarky points various people have made about not needing an HTTPBuilders mailing list miss the point that HTTP’s job is done when the representation is transferred, but an application’s job isn’t done until some actual business operation is performed. So, whether you’re building a SOAP web service or a RESTful service on Web 2.0, sooner or later you’re likely to stumble over XSD’s pitfalls.
The real problem here is that we’re more or less stuck with XSD for the business applications that touch XML’s sweet spot in the middle of documents, databases, and objects — after years of expensive trial and error and endless email threads, XSD interop is getting darn close to tolerable. During that time, no widely-available and reality-tested alternatives that hit that sweet spot have emerged. (DTDs and RELAX NG have weak data typing/binding capabilities in practice … Schematron doesn’t try, but does do a good job of complementing XSD to define data structure contracts that can’t be expressed in a grammar-based schema language).
In short, it’s easy to agree with the Angstifarians 🙂 that there’s a distinct odor of rot coming from the stack of WS-Stuff. Many of the early ideas and specs have passed on but not given a decent burial, and the purifying flames of the REST debate have definitely had an beneficial effect on the current state of the art but the burns haven’t fully healed. Still, it’s not easy to buy the prescription for alternatives unless they really solve equally hard problems with much simpler means. As a masochistic participant in this permathread for about four years now, I’ve yet to see compelling, detailed, practical examples where real business are solving the problems that WS-* addresses with only HTTP+XML (unless one ignores the bazillion person-hours and immense amounts of code that industrial-strength web sites have so far had to deploy). And I’m still waiting for pragmatic guidance on exactly how to put these ideas in practice for an organization that needs something more complex than a stock quote service.
The cure for WS-Rot won’t come from a RESTifarian faith healer, but from plain ol’ hard work — to solidify the XML infratructure, to understand and explain best practice, and above all to build systems that actually work according to their purported principles and let the world know how it’s done.