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

Michael Kay writes:

> Perhaps you just let it be caught by the general ban on duplicate
> components.
 That was the idea.

> But unless you're careful about the wording, that ban also
> catches you out on a linear chain of redefinitions.

I'm pretty sure that's handled OK.  Specifically, the text that says:

"Check for duplicate names (I.e. two or more definitions among the union 
of components and prototype components of the same global name in the same 
symbol set) and reflect a violation of the appropriate constraint if 
found.  Note that redeclaration-prototypes need not be checked for 
duplicates, as each necessarily redefines a similarly named 
prototype-component. "

At this stage of the processing, the redeclarations are all tracked in a 
set of redeclaration-prototypes, which is not set that's being checked for 
duplicate names in the same symbol space.  Once this check for duplicates 
is passed, then the redefinitions are processed. 

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

I think I had convinced myself that there could not be a cycle at the 
document level, but I'm not remembering why I came to that conclusion. 
Certainly the set-of-named-documents approach ACSOOD takes to includes and 
imports means that cycles aren't treated as a problem, but are handled. If 
A.xsd and B.xsd mutually include each other, then each is added to the set 
once (it's a set, so there's no other option) and processed.

As to redefine, if A.xsd redefines T in B.xsd, and B.xsd redefines T in 
A.xsd, then I THINK the same text you newly discovered forces an error. 
There MUST be an explicit top level declaration for T in both A.xsd and 
B.xsd, or the clause you cite triggers failure.  If there are explicit top 
level declarations, then the ACSOOD "check for duplicate names" clause 
quoted above triggers a different error.  So, I think redefine cycles are 
ruled out by ACSOOD, and probably by most reasonable readings of the text 
you discovered.

> That's precisely what I do in my implementation.

Well, I have the general sense that ACSOOD and your implementation are 
very much the same in spirit, if not in every detail.  I suppose that's 
promising in some way or other, but I'm not clear on how it helps us move 
ahead this point.  At the very least, it's somewhat gratifying to me 
personally.

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








"Michael Kay" <mike@saxonica.com>
10/16/2009 05:22 PM
 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at 
XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>
        Subject:        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