Schema implementation problems

I have received several very negative reports on the state of interoperability of tools using XML Schema. The reports come from users from users at a large bank, a fortune 500 company, and a military.

The most common complaint is tools that generate ambiguous XML Schemas. Obviously XML Spy has been the top of the list here, but also there is an IBM tool guilty too, I am told. Ambiguous schemas effectively break everything downstream, regardless of whether some fantasy version of XML Schemas would have been better without them. I call on the workshop or the Schema WG to strongly deprecate implemenations that generate (rather than accept) ambiguous schemas.

(A related complaint, though probably out-of-scope from the committee, is tools that generate non-WF DTDs from XML Schemas. I have also experienced, though not in 2005, tools that generate invalid XML Schemas too. )

Among other complaints are:

• tools that do not accept recursive elements
• tools that do not accept mixed content
• tools that do not accept xsi:type in instances
• tools that do not accept wildcards (I do not have the specifics on this one, this is second hand)

In the category of bad functionality rather than bugs

• tools which don't provide a way or mode to prevent validating with off-site schemas
• tools which give cryptic error messages
• tools which don't warn when no validation has actually been performed (e.g. due to namespace typos)

That there are still so many problems after these years should show anyone but an ostrich that XML Schemas currently sets the bar too high. The desire of some members of the Schema WG that there should be no subsets ('valid is always valdid') has backfired disasterously, for some users: in fact the lack of a simpler subset has all but guaranteed incompatability.

I believe the way forward is simple, and requires no change to the XML Schemas specification.

As a matter of urgency, some group (the workshop? the Schema WG?) should define a simpler profile of XML which sets a lower bar: both a lower bar to encourage vendors to catch up in any areas they are missing, and also a lower bar for users who are willing to forsake features for conservative interoperability. The profile would suit simple messaging in particular, many data-binding applications, but not be influenced by the needs of prose documents.

The XML Mini-Schema profile would invoke the entire XML Schemas spec, then list the features not to be used: in particular, the dynamic and extensible parts of XML Schemas would not be implemented--

• no xsi:type
• no recursive elements
• no wildcards
• no mixed contents
• no wildcards
• a fixed elementFormDefault plus some particular simplifying processing options
• complex type derivation does not need to be checked when validating a document
• all elements and attribute used must have declarations
• validation is always strict
• strictly generate non-ambiguous schemas

I suggest that the Mini-Schema profile should only deal with issues that have been problematic in implementation. For example, I have not heard of "abstract" causing a problem, so it is not on my list (though if others report issues, it would fit.) Revisiting each feature with a minimalist agenda, for example, would guarantee failure by asking the wrong questions. We don't need to guess what looks too much to implement, the facts speak for themselves that the dynamic and extensible features of XML Schemas, though attractive, are not things that many vendors are compelled to get right.

Cheers