Lists Home |
Date Index |
I don't think the problem is people ignoring parts they don't like. The
spec isn't easy to understand or to implement and there is no concept of
certification. Anyone can claim to process XML Schema regardless of the
actual coverage of their implementation. (In fact, the existence of
several partially conformant "implementations" is an important milestone
in obtaining Recommendation status for the spec.) In such an
environment, people ship what they can get away with and work the bug
list over time.
Ian Graham wrote:
> Seems unfortunate that vendors can just ignore normative portions of a
> spec. I can understand differences in implementation where the spec is
> complex, or unclear. But ignoring parts you don't like is simply goofy.
> To reuse your phrase, I would have to call that "bad art" rather than
> "state of the art" ;-/
> Best --
> Bob Foster wrote:
>> Unique particle attribution is normative and not optional, but not all
>> processors check it correctly and some processors check it optionally.
>> Of course that leads to interoperability errors, and not just around
>> UPA, but that's the state of the art.
>> Bob Foster
>> Ian Graham wrote:
>> > I've been fiddling around with very simple schemas that violate the
>> > constraint -- and have found that some schema tools flag UPA errors
>> > (e.g. oXygen), while others (e.g. XML spy) do not. This inconsistency
>> > is, at best, confusing -- but at worst would seem to lead to
>> > interoperability problems, since a designer could build a schema with
>> > one toolset and find it is not acceptable to another.
>> > So am I missing something here? Is UPA really an inviolable
>> > [my interpretation], or is it just a guideline, in the manner of
>> > Appendix E 'Deterministic Content Models (Non-Normative)' in the
>> XML 1.0
>> > specification? And if it's just a guideline, would this not lead to
>> > interoperability problems as I've just outlined?
>> > And, if someone already went down this rat hole, can anyone refer
>> me to
>> > the corresponding xml-dev (or other) thread ;-)
>> > Best --
>> > Ian