Re: Five mechanical approaches to make an XSD profile without getting bogged by individual issues

Henry S. Thompson wrote: (quoting the Databinding Note)
 
"This specification provides a set of basic [XML Schema 1.0] patterns
 known to be interoperable between state of the art databinding
 implementations."

Please note that the Schema Patterns for Databinding WG Note describes the "state of the art" of several years ago.  Considering only what Microsoft has implemented, we noted in a May 2008 comment [1] the WG focused on .NET 2.0, then updated the results for .NET 3.0.  Since then, .NET 3.5 has been released, and .NET 4.0 is in beta test. Recent releases of the XSD-based tools from other vendors and open source projects have kept pace, and all have advanced the state of the art for interoperability.

See also the position paper [2] for the 2005 Schema Interoperability Workshop which argued " Microsoft's position is that the XSD spec is far from perfect, but has been valuable to us and the XML industry as a whole. It could be even more valuable to us all, if vendors and OSS community invest some effort to fully implement XSD validation, perform interoperability tests, and fix ambiguities and errors in the original recommendation."  

Taking off the spokesperson hat and speaking only for myself: I am very sympathetic to the critiques of XSD, and in another time would have enthusiastically endorsed Rick's Recommendations to fix its foundations rather than patch its cracks.  My experience in the XML and web services teams at Microsoft has convinced me, however, that attempts to fix XSD (and XML for that matter) do more harm to the core value proposition of interoperability than they benefit functionality, usability, and so on.  XML/XSD with all its warts is used in an astonishingly large number of ways and places, and I've learned about many them by having to deal with the fallout from "improvements" to the specs and implementations.  Even the apparently minor changes in  XML 1.0 5th edition have great potential to undermine XML-based interoperability, in ways that I never thought about until we tried to implement it and found that it created chaos in the higher levels of the XML stack. If XSD 1.1 scrupulously avoids breaking changes while fixing some of the flaws, it has some chance of getting traction, I don't know.  

As the TAG discovered, versioning is an EXTREMELY hard problem that we really don't know how to solve, so W3C needs to be excruciatingly careful about new versions of the specs for technologies that are unknowingly used by hundreds of millions of people every day.  That's not to say we're stuck with the status quo, only that replacements for XML / XSD 1.0 are going to have to prove themselves in new environments first, and we should be assuming a conscious migration rather than a silent update from the current to the new standards.

[1] http://lists.w3.org/Archives/Public/public-xsd-databinding-comments/2008May/0000.html
[2] http://www.w3.org/2005/05/25-schema/microsoft.html

Received on Friday, 29 May 2009 15:53:09 UTC