Lists Home |
Date Index |
Most interesting were the recommendations for future committee work,
which can be summed as: For God's sake, don't add anything; concentrate
on errata and conformance tests.
Disclosure: We also make XML tools and depend on XML Schema validation
and design for part of our income. We are not, however, XML Schema
validator implementors. We took a run at this a couple of years back and
decided the world didn't need yet another broken, incomplete
implementation. Given the convoluted specification and the lack of
conformance tests, any other outcome seemed highly unlikely.
Rick Jelliffe wrote:
>>The W3C has posted the minutes for the workshop a couple of weeks ago,
>>which have links to the presentations
>>The experience reports submitted in advance are at
> Some interesting quotes from the pre-submitted documents:
> ACORD: "...we have random implementations and understandings of the
> specification and it is usually up to the unwary user at the most
> inopportune moment to find out that a feature is not supported. "
> BEA: "we believe that the complexity of Schema is, in many scenarios,
> unnecessary, and often actively harmful. More than anything, this is the
> feedback we hear from our customers and end users. We are also concerned
> that Schema’s complexity may be the root cause of so many incomplete
> and/or incorrect implementations."
> BT: "In our experience, XML Schema is implemented inconsistently in vendor
> tools, especially those which used schemas to generate mappings into code
> and other forms of data." "Working around interoperability issues with
> vendor supplied tools is difficult and sometimes impossible when using XML
> Schemas published by third-parties, standards organisations and
> HL7: "HL7's experiences with designing schemas that work across a broad
> array of tools has been extremely disheartening."
> IBM: "Anecdotal feedback from the Web services community has suggested
> that inconsistent support for certain valid XML Schema constructs across
> the various development tool environments has contributed significantly to
> the interoperability challenges faced by Web services developers."
> Microsoft: "Rick Jelliffe [RJ05] describes the situation faced by an
> actual customer where incomplete support for XSD in various products has
> “stuffed up the ready interoperability they thought they were buying into
> with XML.” That sums up the problem nicely and mirrors the experience of
> many of our users."
> OAGi: "Complex type derivation by restriction simply does not work."
> Rogue Wave: "Many customer issues come from schemas that are not valid. In
> almost all cases this is the result of a schema generated by a tool."
> SAP: "In a heterogeneous environment, usability, implementation and
> language binding issues impact the choice of features that are supported.
> This led SAP to have different levels of support for XML Schema features
> due to the impedance mismatch between the language constructs and XML
> Schema constructs or the frequency of use of certain XML Schema
> constructs." "SAP favors this direction (a profiling mechanism) as a
> catalog of profiles and their constraints could then be published and used
> as basis for interoperability when designing a certain class of language
> bindings and applications as well as business vocabularies. Further, it
> would help reduce interoperability issues for hard to implement and
> understand features of XML Schema."
> Sun: "When people run these broken schemas against our schema compiler, we
> reject it as an error, which only make them think that ours is broken.
> This trouble-shooting can get quite complicated if it involves in a type
> hierarchy, substitution groups, and/or wildcards."
> Rick Jelliffe
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>