OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] incompatible uses of XML Schema

[ Lists Home | Date Index | Thread Index ]

Just don't use the tools that don't conform.

It's not actually that hard to write a conformant schema processor, or at
least to get to the 98% mark where the only non-conformances are in areas
where the spec writers themselves still have debates about the exact
meaning. I did it in less than six months with Saxon. If people stopped
using non-conformant tools, suppliers would stop producing them.

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: Gregor [mailto:iamgregor@gmail.com] 
> Sent: 27 April 2005 05:45
> To: Rick Jelliffe
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] incompatible uses of XML Schema
> 
> >People *are* confused by schema-using applications (other 
> than validators)
> 
> I would like to say something about the usage of XML Schema/validators
> nonetheless:
> 
> I am currently facing the a problem with XML processors that are
> evaluated for their XML Schema validation capabilities in Industry
> Standards (CIDX, PIDX, RosettaNet for a start).
> 
> The limitations of one of the processors are huge (no id-constraints,
> no wildcards, no mixed-attribute) so I have resorted to classifying
> the features of XML Schema and then applying the classification to the
> Industry Standard vocabularies.
> 
> Since, for example, no industry standard is using wildcards all test
> cases that test for wildcards need not be run on the processors for
> the output is irrelevant in the scenario at hand.
> 
> I also see the problem we will face if the standards change
> significantly and will deal with this in my summary of the whole
> benchmark.
> 
> On the other hand I see some Pareto-Priniciple here ("vital few and
> trivial many"), because the industry schemas (and many other
> vocabularies) skip the fancy XML Schema constructs (like
> id-constraints, wildcards, notations, model group definitions (last
> one not that fancy, I know :-))
> 
> If I wanted my head chopped off (figuratively) in this mailing list I
> would suggest a new classification of parsers offering:
> - basic support (e.g. element declaration, complex type definition,
> simple types definition, attribute declaration/uses, particle and
> model group)
> - extended support (notation declaration, attribute group definition,
> model group definition, identity constraint definition)
> 
> This would in my opinion be more honest than today's "minimally
> conforming parser" (see http://www.w3.org/TR/xmlschema-1/ 2.4
> Conformance) because after running the XML Schema test suite with
> processor failing as many as 33% of the tests I sometimes wonder
> whether full XML Schema conformance is not reserved for the really
> good tools like the validator provided by the W3C, xerces or any other
> tool that I have not tested that was designed with immense effort.
> 
> But since I do not want to get my head chopped off I will not suggest
> the above (it is anyway lame to changes standards after issue). I just
> wonder writing this, whether a reduced version of XML Schema could
> have resolved the complexity issues that made people develop easier to
> handle schema languages.
> 
> If this was my fairy-godmother-visiting-day I would wish the world
> more and more and even more test cases for XML Schemas (schema only
> and schema/instance) because testing and tracking down the errors is
> in my opinion a pillar of ensuring standard compliance and standard
> awareness.
> The release of the results of a standardized extensive W3C test suite
> would be a better indicator of compliance (the ISO 9001 of XML
> Schema:-) than the "Standard Compliant" tag that accompanies almost
> every XML Processor (sales rep: "Oh yes, we are fully standard
> compliant. There are just some very minor issues concerning...)
> 
> Anyway, my contribution to this thread is, that even if a parser is
> not "minimally conforming" it might still be a good choice based on
> the scenario at hand (and I think I have found a way to test exactly
> this).
> 
> Some parser can be wrong some of the time, as long as not all the
> parsers are wrong all of the time :-)
> 
> Gregor
> 
> -------------------------
> 
> Beat me with arguments, not with insults (posts resorting to the
> latter shall be ignored)
> 
> 2005/4/26, Rick Jelliffe <ricko@allette.com.au>:
> > Dare Obasanjo wrote:
> > 
> > >We shouldn't confuse schema validation issues with 
> XML<->object mapping
> > >issues. From the sounds of things the problem is the latter not the
> > >former.
> > >
> > There is a difference between tools that ignore some 
> constraints (e.g. a
> > tool
> > that doesn't use key/keyref in its machinations), a tool 
> that barfs on
> > certain components in an XML Schemas schema, and a tool 
> that does not
> > handle dynamic typing with xsi:type in instances.
> > 
> > People *are* confused by schema-using applications (other 
> than validators)
> > because they expect to be able to use any schema.
> > 
> > It reminds me of a certain famous structured editor in the 
> early 1990s: its
> > internal model did not have attributes, so it did not 
> support round-tripping
> > of attributes from SGML.  They soon found that they needed 
> to support
> > them, to maintain their credibility.  Maybe it shows that 
> XML Schema tools
> > are not mature yet: indeed, the disappearance of this 
> problem will be a sign
> > that XML Schemas tools are mature enough for cautious 
> businesses to take
> > seriously. These incompatabilities indicate that we are 
> still at the "early
> > adopter" stage, don't they?
> > 
> > Cheers
> > 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>
> > 
> >
> 
> -----------------------------------------------------------------
> 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>
> 
> 






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS