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:
In the category of bad functionality rather than bugs
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--
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.