Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ?

On 29 Sep 2009, at 05:24 , XMLSchema at XML4Pharma wrote:

> We, the CDISC XML-Tech Governance Team (and other CDISC teams) have  
> developed a number of extensible standards for exchange of clinical  
> data and for submitting information to the regulatory authorities  
> (FDA).
>
> CDISC is a Standardization Organization active in the healthcare  
> world.
>
> Our extension mechanism is based on the “import” and “redefine”  
> elements of XML-Schema.
>
> We now have a serious dispute with one technology vendor (Altova)  
> about the way “import” and “redefine” are used. Instance files of  
> one of our extensions (so-called “define.xml”) validate well in all  
> major validators and XML-editors, except for the products of this  
> one vendor.
>
> When confronted with this result, the reaction of Altova essentially  
> is that “Altova is right, all others are wrong”. The dispute and  
> discussion with Altova can be followed at:
> http://www.altova.com/forum/default.aspx?g=posts&m=1000005665
>
> The issue were not so serious if it were not that our standard  
> “define.xml” is a standard for submission of information to the  
> regulatory authorities, and these are (mostly) using the Altova  
> product for validation.
>
> We now want to escalate the issue to the W3C itself, and would like  
> to know what the mechanism is to do so.
>
> Jozef Aerts
> CDISC XML-Tech Governance Team
>

I believe that some standards bodies have mechanisms for requesting
authoritative interpretations of doubtful points in specifications
published by those bodies.  W3C does not have any formal mechanism
for such interpretations, but you can certainly request an opinion
from the W3C XML Schema Working Group by sending mail to the
XSD comments list at www-xml-schema-comments@w3.org (or by raising
a Bugzilla issue against XSD 1.0).

The public record shows, however, that the XML Schema Working Group
has already addressed the question of what happens when the same
schema document is referred to both by a direct import or include
and indirectly through a reference to another schema document
which redefines the first (see Bugzilla bugs 2330, 2557, 2824,
and on related issues also 2826 and 5425, in the W3C public
instance of Bugzilla at http://www.w3.org/Bugs/Public/).  As the
record shows, the Working Group has been unable to resolve those
issues in part because the group has not been able to reach
consensus on the meaning of the 1.0 specification in the cases
in question.

Reviewing the discussion record on the Altova forum I am struck by
the repeated remark that the CDISC team has consulted "several
distinguished members of the W3C XML-Schema working group" who
confirmed CDISC's interpretation of the XSD 1.0 spec.  I can only
hope that these consultations took place some years ago, before
the working group realized just how divergent its interpretations
of the specification are; if you have consulted with any member
of the working group in the last four years about this case, and
they have failed to mention to you that the spec invites multiple
contradictory interpretations, and that the working group has
been unable to agree on what a single interpretation, then I
fear they have misled you sadly.

I'm also struck by the report that XML Spy is an outlier in its
behavior on this case.  The work I did in 2007 on an analogous
case suggested that depending on how they were invoked, the
eight processors tested behaved in nine or ten different ways
(fourteen if you count error messages reporting different
diagnoses of the problem as different behaviors).  The
work is described in a document available at
http://www.cmsmcq.com/2007/schema_composition/model.xml
(the test cases which elicit these different behaviors are
described in section 5.2.2 and its subsctions).

The XSD 1.0 specification does not explicitly address the case
when the same schema document in referenced both directly
(via import or include) and indirectly (via redefine).  The
rules for import specify that the components imported
via the import or include should be present in the resulting
schema; the discussion of redefine says that the effect of
redefine is pervasive.

Some readers interpret this to mean that the pervasive-redefinition
rule overrides, or modifies the effect of, the import and include
rules.  On this reading the schema is legal and the components
are present in their redefined form (and only that form).  This
reading effectively attaches to the rules for include and import
an unspoken exception to the effect that the components imported
or included are present in the resulting schema unless they are
redefined by some other schema document reference.

Other readers interpret the rules as requiring that the
components in question should be present both in their
original and in their redefined form, which means that the
schema violates the rule that there must be at most one
component of any kind with a given expanded name, and thus
that the schema should be rejected.

It is my personal belief that the most plausible interpretation
of the specification is the latter; as you have observed, at
least some implementors disagree and prefer the other
interpretation.

The inability of the XML Schema working group to agree on a
normative interpretation of XSD 1.0 has led to the agreement to
deprecate the redefine element in XSD 1.1.  My personal
recommendation is either to avoid redefine entirely or to
avoid the use of schemaLocation information in your primary
schema documents, restricting the identification of specific
schema documents to top-level 'driver' documents, or to
invocation-time parameters and options passed to the
validator.

I hope this helps.

Michael Sperberg-McQueen



-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Tuesday, 29 September 2009 15:58:34 UTC