The W3C has published a working draft of the XML Schema Patterns for Databinding specification, aimed at increasing interoperability among XML databinding tools.
Spec co-editor Paul Downey answered some questions about the spec for InfoQ and started out by separating the two main schema use cases, first as a validation language, secondly as a means of describing the expected structure and content of an XML document. The databinding specification focuses on the description use case, where some sort of agent — for example a development environment or run-time component — consumes a Schema, possibly wrapped inside a WSDL document, and uses it to map between XML and a data model, which can be to a programming language, a database or an XML alternative such as JSON or YAML.
As developers who have tried to use tools from different vendors have learned the hard way, different databinding implementations support these concepts with different quality. Paul pointed to a quote on the WG page from the Chairs' report from the W3C Workshop in Schema User Experiences which led to the formation of the Working Group:
There was significant support for the idea of a written ‘profile’ of XML Schema which would document the sweet spot for purposes of data binding, or for other specific domains. The word profile is problematic; what was meant was not a language subset, but only a definition of the sweet spot in existing processors, which would allow schema authors to get better results and better user experience when data binding tools are used, and which would tell implementors in the relevant domain which parts of schema users are most likely to expect them to support well."In Paul's words, "the problem isn't so much that Schema sucks, or that databinding implementations suck, it's that they all suck differently." As opposed to having workarounds based on suggestions from vendors that typically just shift responsibility from one to the other, the idea of the spec is to get this topic addressed through a standards body. Quoting Paul again:
A fairly typical scenario is for a vendor to suggest changing your schema or WSDL to work round an issue with their tool, only to result in other implementations failing. We call this process a "barf dance".
The specification is unusual in that much of it is machine process-able. It defines a schema pattern using a single XPath expression and identifies each pattern with a stable URI. This enables the building of a patterns detector in the form of a Schematron schema or XSLT stylesheet to evaluate the patterns used within a description.
Questioned whether the members of the working group have actually researched and tested tools for interoperability to find these patterns, Paul replied:
BT, who I represent in the WG, has a large amount of experience with a wide range of databinding toolkits since 2001 which we have brought to the working group. We also are in the process of building a test suite which takes simple example schemas and exposes them as "echo" service operations. Firing instance documents at such a service allows us to quickly and generically evaluate a databinding implementation.He also commented on his views about the spec's impact:
Well immediately the "Basic" patterns detector in conjunction with the WS-I Basic Profile serves as a useful quality gate when publishing WSDLs. The W3C plans to host the detector as a validation service. Going forward we really need help from developers of toolkits in publishing logs of running our test suite against their implementations. We've had a good response so far from the Open Source community, but have few vendors participating. So if you are experiencing difficulties using a databinding implementation from a big-name, you might question why they aren't involved in the Working Group! We also need help from publishers of schemas to ensure we cover their "Advanced" patterns. This will assist vendors to understand where they can concentrate their efforts in improving their tools.
Finally, Paul asked for the community's contribution to making the spec as useful for real-world tasks as possible:
Much of the value of a W3C specification comes from its open process. We are working in public and welcome contributions in the form of comments, contributed patterns, test cases and testing reports.
More information is available in the specification document and the Working Group page.