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.