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

 

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: 16 October 2009 21:35
> To: Michael Kay
> Cc: 'Henry S. Thompson'; 'XMLSchema at XML4Pharma'; 
> xmlschema-dev@w3.org
> Subject: RE: Escalation mechanism for different 
> interpretation of W3C XML-Schema specification ?
> 
> Michal Kay writes;
> 
> > It's not clear what answers it gives for more complex redefinition 
> > graphs.
> 
> Well, it's been a long time since I've looked at it.  I guess 
> I assume that all redefinition graphs are in fact trees, I.e. 
> each redefine can redefine only one thing

Well, there's a graph of schema documents, and a graph of components. If
there's a cycle in the graph of schema documents then there's potential (but
not the necessity) of a cycle at the level of components. A cycle at the
component level is clearly a nonsense, and my inclination is that the same
is true at the document level.

Even without cycles, though, it's not clear to me how ACSOOD handles:

A includes B
A includes C
B redefines X defining a restriction of type T
C redefines X defining a (different) restriction of type T

Perhaps you just let it be caught by the general ban on duplicate
components. But unless you're careful about the wording, that ban also
catches you out on a linear chain of redefinitions.

I noted the statement in your proposal: "Note that the information needed to
determine a redeclaration prototype is easily determined from the
<redefine>ing XML schema document;  the text of a redeclaration always
explicitly refers to the particular schema document containing
(specification of) the component being redefined. " I was surprised to see
this, but I now see that the spec does say (in Schema Representation
Constraint: Individual Component Redefinition) "In all cases there must be a
top-level definition item of the appropriate name and kind in the
<redefine>d schema document." I now realise I haven't been enforcing that
rule: I only require it to be present in "the schema corresponding to" the
<redefine>d schema document. If A includes B, and R redefines A, then I
allow R to contain redefinitions of components that are actually defined in
schema document B. And the Dutch schema I've been working on today
(http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd) certainly takes
advantage of that freedom.

> 
> > And it doesn't appear to have anything to say about 
> chameleon include.
> 
> ...  I think this probably means that I would have to augment my 
> list of schema document abstraction to actually make it a 
> list of (schemadoc, targetNamespace) pairs, 

That's precisely what I do in my implementation.

Regards,

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