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

I strongly urge you to read Michael Sperberg-McQueen's note carefully. 
While, as noted below, some of my preferences for resolving ambiguities 
happen to be different from his, I believe that his email very accurately 
and carefully summarizes the state of play on this issue.  Let me just 
quote and comment on a few sections of Michael's note:

> 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.

Yes, that's what it says, and it's contradictory.

> 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.

Yes, those are at least two of the widely held positions as to what was 
"really" intended, and I don't think I'm aware of any others.

> 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.

I happen to be one of the others who would prefer that the redefine be 
pervasive, but the important point here is that either interpretation is 
plausible, and we agree on that.

> 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. 

Here, I'd like to add one bit.  While Michael is correct that the working 
group has "agreed" on this, some of us joined in that agreement with some 
hesitancy, because we believe that <redefine> has seen widespread use, 
including in cases that do not trigger (or at least do not as clearly 
trigger) the ambiguities that are causing trouble here.  So, in light of 
those concerns, the working group also agreed to make the deprecation of 
<redefine> a so-called Priority Feedback issue.  Quoting from the working 
draft [1]:

----
Note: The redefinition feature described in the remainder of this section 
is ·deprecated· and may be removed from future versions of this 
specification. Schema authors are encouraged to avoid its use in cases 
where interoperability or compatibility with later versions of this 
specification are important.

Editorial Note: Priority Feedback Request

The Working Group requests feedback from readers, schema authors, 
implementors, and other users of this specification as to the desirability 
of retaining, removing, deprecating, or not deprecating the use of 
<redefine>. Since the <override> facility provides similar functionality 
but does not require a restriction or extension relation between the new 
and the old definitions of redefined components, the Working Group is 
particularly interested in learning whether users of this specification 
find that requirement useful or not. 
----

So, if any readers of this thread have opinions on the plan to deprecate, 
the Schema Working group would welcome hearing about them.  I think it's 
worth noting that this thread has already made clear that: 1) this is a 
known area of complexity and the working group has already tried and so 
far failed to find an easy resolution acceptable to all; 2) there are 
incompatibilities in widely deployed implementations, so any clear 
resolution is quite likely to make someone with an investment in code very 
unhappy.  That's not to say I wouldn't like it cleaned up;  indeed, I'm 
among those who put many months into trying a few years ago (as did 
Michael). I'm just pointing out that our choices may be to deprecate or 
undeprecate, but going further to remove the ambiguity is likely to be a 
significant effort that will introduce incompatibilities for at least 
somebody.  Maybe or maybe not we could find a way to warn people off from 
the most troublesome cases, but I know that Michael and perhaps others 
will correctly point out that the whole conceptual framework for this 
"composition" function is sufficiently shaky in the current drafts that 
any fix short of a complete rewrite is likely to leave things in a messy 
state.

Noah

[1] http://www.w3.org/TR/xmlschema11-1/#modify-schema

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 29 September 2009 16:55:27 UTC