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

While I think many of your criticisms of xs:redefine and complex type
restriction and indeed xs:override are valid, I personally don't accept the
premise that XSD should be constrained or influenced by the data typing
paradigms of conventional programming languages. XML and XSD are first and
formost intended for designing hierarchic document structures (a discipline
with a far longer tradition than programming), and the fact that
conventional programming languages don't support such structures very well
means in my view that it's best to switch to languages that do.

Regards,

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

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dennis Sosnoski
> Sent: 02 October 2009 23:10
> To: noah_mendelsohn@us.ibm.com
> Cc: XMLSchema at XML4Pharma; C. M. Sperberg-McQueen; 
> xmlschema-dev@w3.org
> Subject: 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:44:33 UTC