[
Lists Home |
Date Index |
Thread Index
]
>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>
>
>
|
