Tim Ewald has an astute post entitled PaulD's new XSD data binding WG where he discusses a recently chartered W3C working group. He writes

Paul responded to yesterday's post to explain the need for the new W3C XML Schema Patterns for Databinding Working Group, which he chairs. He points out that the move by the WS-I to deprecate encoding in favor of literal schema was based on a reasonable argument (that there is no spec for how to translate an XSD in a WSDL - which describes a tree of named structural types - into an input to SOAP encoding - which acts on a graph of unnamed structural types) but that the end result made interop harder because it opened up the door to using all of XSD. I disagree. The WSDL spec opened the door to using all of XSD for both encoded and literal bindings. The work that SOAPbuilders did provided a set of test cases for mapping common types and structures. It did not, however, address questions like “how do you map substitution groups to code using an encoded binding”, something that is completely legal according to WSDL. In other words, the shift from encoding to literal in no way widened the number of databinding cases we had to be concerned about. That's a red herring. The real problem has been the lack of SOAPbuilders-style test suites to cover more of XSD or the lack of a formal specification that narrows XSD to a more easily supported subset (an option that the WS-I discarded).

This is one of those issues which that which I use to blame on the complexity of XSD but have adjusted to also blaming vendors of XML Web services toolkits as well. The core problem is that every vendor of XML Web Services toolkits pretends they are selling a toolkit for programming with distributed objects and tries their best to make their tool hide the XML-ness of the wire protocols (SOAP), interface description language (WSDL) and data types (XSD). Of course, these toolkits are all leaky abstractions made even leakier than usual by the impedance mismatch between XSD and the typical statically typed, object oriented programming language that is popular with the enterprise Web services crowd (i.e. Java or C#).

The W3C forming a working group to standardize the collection of hacks and kludges that various toolkits use when mapping XSD<->objects is an attempt to standardize the wrongheaded thinking of the majority of platform vendors selling XML Web Services toolkits.  

Reading the charter of the working group is even more disturbing because not only do they want to legitimize bad practices but they also plan to solve problems like how to version classes across programming languages and coming up with XML representations of common data structures for use across different programming languages. Thus the working group plans to invent as well as standardize common practice. Sounds like the kind of conflicting goals which brought us XSD in the first place. I wish them luck.


Monday, December 12, 2005 2:25:43 AM (GMT Standard Time, UTC+00:00)
>"..collection of hacks and kludges that various toolkits use when mapping XSD<->objects.."

Dare, given the situation exists, what would your advice be to folks (devs, not toolkit vendors) on how to work in this environment?
Monday, December 12, 2005 5:59:58 PM (GMT Standard Time, UTC+00:00)
My advice would be this:

(i) if you are consuming web services, then consume them as XML instead of using the object to XML mapping that your toolkit provides. Most toolkits allow you to get at the underlying XML of a SOAP response.

(ii)if you are exposing web services then use as few XSD features as possible. I'd limit it to basic types (integer, float, boolean and datetime) and constructs (sequence, any, choice) with a few other limitations. This can be achieved by taking a code-first approach to building the service and not using 'fancy' datatypes like the ADO.NET DataSet.
Monday, December 12, 2005 8:38:36 PM (GMT Standard Time, UTC+00:00)
Its ironic that MSFT is the bigest pusher of the xsd->object philisophy, xml being too complex for mort.
Comments are closed.