W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2013

Re: Redefinition of group, who's correct

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Sun, 31 Mar 2013 16:22:31 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, XMLSchema-dev <xmlschema-dev@w3.org>
Message-Id: <19FA97CF-7C17-4B03-88B7-1C09B2AB955C@blackmesatech.com>
To: Pierre Attar <pat@tireme.fr>

On Mar 20, 2013, at 11:56 AM, Pierre Attar wrote:

> Hi,
> 
> I have a problem using group redefinitions and validating both with XMLSpy (who complains) and Oxygen (who validates).
> My question : who is correct ? Where a I wrong ?
> 
> Note: my schema are a lot more complex but I try to make a sample (non realistic) in order to isolate my question.
> 
> Here is the situation :
> 
> base.xsd declares a group called essai :
> ...
> 
> 
> other.xsd only includes base.xsd
> ...
> And now, redefine .xsd both redefine base.xsd and includes other.xsd
> 
> ...
> At this time, XML spy complains but not oxygen 14.2. If I remove the include, no problem found.

The upshot is that in the schema described by redefine.xsd, the components
declared in base.xsd are both redefined (via the redefinition of base.xsd)
and included as-is (via the inclusion of other.xsd and the inclusion, there,
of base.xsd).

Such situations do not, I believe, have any non-contradictory interpretation 
in the XSD spec, and (as one might expect under the circumstances) 
processors differ in how they attempt to make sense of the contradictory 
rules in the spec.

The description of xs:redefine says (simplifying slightly) that the redefined
version of the essai element should be included in the schema.  The 
description of xs:include says (again simplifying) that the unmodified version
of the 'essai' element should be included in the schema.  

If both of these descriptions are taken at face value, then the schema described
by redefine.xsd has two top-level declarations for 'essai' and does not conform
to the spec.  That appears to be the reading adopted by XML Spy.

The spec also says in passing (and without any concrete explanation of what 
is meant) that redefinition has "a pervasive impact".  This is taken by some
implementations to mean that the inclusion of base.xsd should essentially 
be ignored (or else be regarded as covered by the redefinition request).
That appears to be the reading adopted by Xerces and/or Saxon, which
Oxygen is using.

Of the two readings of the spec, the second one (which allows this schema
to be legal) is probably closer to what the designers of the redefine
construct wanted to achieve, and most users probably find it more useful.
But the first reading seems to me to be a perfectly plausible -- in fact, 
somewhat more plausible -- reading of what the spec actually says about
the meaning of the constructs involved. 

Both readings seem to involve ignoring parts of the spec:  the first reading
ignores the sentence about redefinition having pervasive impact as being
unclear or meaningless, or else must assign it some meaning compatible
with the rest of the reading.   The second reading ignores all the rules in 
section 4 of the spec about the meaning of xs:include.   

To answer your questions directly:

Who is correct?   The spec is too badly drafted to allow this question to have
a clear answer.  So:  no one is correct, or everyone is correct.  For all
practical purposes, we must act as if the spec said explicitly that the 
behavior of conforming processors in cases like this one were
implementation-dependent.

Where are you going wrong?  You are going wrong by including
constructs in your schemas whose meaning is implementation-dependent
(in this case because the meaning is not well defined by the XSD
spec), and then expecting different processors to behave consistently.
If you want consistent behavior across processors, eliminate the 
double reference to base.xsd.  

The simplest way to avoid implementation-dependent processing
of include, import, and redefine is to remove all instances of xs:include,
xs:override, and xs:redefine, and all instances of @schemaLocation
on xs:import, from any schema document that actually declares
anything (elements, attributes, types, ...), and move them into 
distinct 'driver' documents which contain no declarations of their
own, but only references to other schema documents:

In the ideal case:

  - "class 1" schema documents contain declarations and definitions;
    if they have xs:import elements, those elements have no
    schemaLocation attributes.

  - "class 2" schema documents contain nothing but a top-level
    xs:override or xs:redefine pointing to a class-1 schema 
    document.

  - "class 3" schema documents contain nothing but xs:include
    (and possibly xs:import) elements pointing to class-1 or class-2 
    documents. If xs:import elements are present, they may carry 
    schemaLocation attributes.

In complex cases, you may end up with a class-2 document 
needing to redefine the entire set of components for a namespace,
so it may end up pointing to a class-3 and not a class-1 document.

In any case, avoid multiple references to the same schema 
document and avoid cyclic references (A refers to B refers to 
C refers to ... refers to A):  they have interoperability problems
out of all proportion to their convenience.
 

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************
Received on Sunday, 31 March 2013 22:23:06 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 22:23:06 UTC