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

Hi Noah,

IMHO both xs:redefine and xs:complexType restriction should be 
eliminated. With respect to the increasingly important area of XML data 
binding for programming languages, redefine and complexType restriction 
are generally ignored for the simple reason that they have no equivalent 
in terms of data models. The object oriented programming equivalent of 
complexType restriction would be to define a subclass by eliminating 
information from the parent class, which is a bizarre concept in 
programming terms - if you want a limited representation which is not 
supported by the current data model you either refactor the data model 
to support the particular subset you want or use a representation which 
has more features than you need, with semantic constraints on the usage. 
There are times when this limitation of object oriented programming is 
inconvenient, but I suspect the vast majority of developers would agree 
that the benefits in terms of clean data models more than outweigh the 
inconvenience.

Beyond this, the very nature of complexType restriction, which requires 
repeating all portions of the original model which are being retained, 
creates brittle definitions.

redefine is an even stranger operation, effectively performing surgery 
on an existing definition to deform it in ways never intended by the 
original designers. One consequence is that anyone looking at an 
instance of an XML structure defined by a schema needs to be aware of 
other schemas which may have modified the original schema definition. 
Requiring knowledge of the entire set of schemas involved in a document 
in order to understand one particular component of the document is 
contrary to good design principles.

It's hard for me to see how xs:override represents any kind of 
improvement on redefine, so asking for feedback on deprecating redefine 
while adding override into the mix seems deliberately futile. From my 
point of view override suffers from the same design failures as 
redefine, and should also be eliminated.

I realize that many uses of W3C schema are not concerned with data 
binding, but I'd suggest that the difficulty of modeling these 
constructs in terms of modern programming language structures shows that 
they could be eliminated without significantly harming the usefulness of 
schema.

  - Dennis

Dennis M. Sosnoski
XML and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



noah_mendelsohn@us.ibm.com wrote:
> 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 Friday, 2 October 2009 22:10:45 UTC