W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2009

Re: Question on XSD 1.1 cyclic <override>

From: Kevin Braun <kbraun@obj-sys.com>
Date: Mon, 28 Dec 2009 13:43:35 -0500
Message-ID: <4B38FC57.2050009@obj-sys.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
CC: www-xml-schema-comments@w3.org
Thanks, Michael.

I think it is not true that O1=O1' and O2=O2', but the result is 
basically the same:

(1) schema(D1) = builtins + immed(D1) + schema(override(O1,D2))

override(O1,D2) will have an override child, O2', which will be:
<override schemaLocation="a.xsd">
   <element name="elementA" type="string"/>
   <element name="elementB" type="string"/>
</override>

Expanding the last term:
(2) schema(D1) = builtins + immed(D1) +
   builtins + immed(override(O1,D2)) + schema(override(O2', D1)

override(O2',D1) will have an override element O1' which will be:
<override schemaLocation="b.xsd">
   <element name="elementA" type="string"/>
   <element name="elementB" type="string"/>
</override>

Expanding the last term:
(3) schema(D1) = builtins + immed(D1) +
   builtins + immed(override(O1,D2) +
   builtins + immed(override(O2',D1) + schema(override(O1',D2))

Simplify a bit:
(4)  schema(D1) = builtins + immed(D1) +
   immed(override(O1,D2) +
   immed(override(O2',D1) + schema(override(O1',D2))

override(O1',D2) will have an override element equivalent to O2'.  
Expanding the last term,
(5) schema(D1) = builtins + immed(D1) +
   immed(override(O1,D2) +
   immed(override(O2',D1) +
   builtins + immed(override(O1',D2)) + schema(override(O2',D1)

We have added in the last term before; it is safe to drop it now.  Doing 
that and simplifying gives:
(6) schema(D1) = builtins + immed(D1) +
   immed(override(O1,D2) +
   immed(override(O2',D1) +
   immed(override(O1',D2))

If immed(D1) = immed(override(O2',D1)) AND immed(override(O1,D2) = 
immed(override(O1',D2)), all is well.  If not, we have conflicting 
declarations.  The first conjunct is false (the second is true).

Where the spec talks about target sets, it addresses the situation of a 
document D containing an override element E such that D is in E's target 
set.  Such a case is okay if
[1] override(E, D) = D.  In the above example, [1] is met for all such D 
and E (while it is true that  D1 != override(O2',D1), it is also true 
that O2' is not contained by D1).  Thus, it seems to me that [1] is not 
a sufficient condition.  It was met, but still there was a conflict.

Actually, I think [1] may also not be a necessary condition for avoiding 
conflicts.  You may have a schema document D that contains two override 
elements, E1 and E2, such that D is in the target set of E1, or E2, or 
both, and D != override(E1,D) and D != override(E2,D) and where the 
differences lie entirely in the transformed override elements, which 
doesn't necessarily cause conflicting declarations.

To be a little more general, suppose you have a cycle of overrides 
D1->D2->..->Dn->D1, and you are going to find schema(D1).  Suppose there 
are some i, j such that:
- i < j
- Dj has an override for element E
- there are no overrides for element E in D1..Di
- E is declared in Di
Then, I think, there is going to be a conflicting declaration for E in 
schema(D1).  However, I suspect it could at the same time be true that 
schema(Dj) would not have any such conflicts.  It seems that whether 
such a conflict arises depends not only the whole cycle, but also on 
where you begin in the cycle (ie, for which Dk you are finding 
schema(Dk)), and thus that the determination for conflicts is rather 
more complicated than what the spec would lead us to believe.

--Kevin

On 12/27/2009 6:55 PM, C. M. Sperberg-McQueen wrote:
>
> On 23 Dec 2009, at 14:53 , Kevin Braun wrote:
>
>> The spec seems to say that if override(O1, D1) = D1 and override(O2, 
>> D2) = D2 (both true, I think) then it is okay that target_set(O1) 
>> includes D1 and target_set(O2) includes D2.  Yet, it seems that 
>> schema(D1) should contain two conflicting declarations for elementA.
>
> I agree that schema(D1) should (and does) contain conflicting
> declarations for elementA.
>
> But the salient condition is not
>
>   override(O1, D1) = D1 & override(O2,D2) = D2
>
> (which are indeed true, unless I'm missing something), but
>
>   override(O1,D2) = D2 & override(O2,D1) = D1
>
> which is false in both conjuncts.  If you replace both overrides
> with equivalent includes of modified schema documents, and
> continue substituting equivalents for equivalents, you do get a
> cyclic include of two schema documents (call them a'.xsd and
> b'.xsd) which declare elementA and elementB of type string.
> But you also have the original declaration of a.xsd, which
> conflicts with that of a'.xsd.
>
> Algebraically:
>
> (1) schema(D1) = builtins + immed(D1) + schema(override(O1,D2))
>
> Expanding the last term this gives
>
> (2) schema(D1) = builtins + immed(D1)
>                  + builtins + immed(override(O1,D2))
>                  + schema(override(O2',D1))
>
> where O2' = the element O2 in override(O1,D2).  Here, O2' = O2,
> so (simplifying) we have
>
> (3) schema(D1) =  builtins + immed(D1) + immed(override(O1,D2))
>                  + schema(override(O2,D1))
>
> Again expanding the last term this gives
>
> (4) schema(D1) = builtins + immed(D1) + immed(override(O1,D2))
>                  + builtins + immed(override(O2,D1))
>                  + schema(override(O1',D2))
>
> where O1' = the element O1 in override(O2,D1).  Here, O1' = O1,
> so we have
>
> (5) schema(D1) = builtins + immed(D1) + immed(override(O1,D2))
>                  + immed(override(O2,D1))
>                  + schema(override(O1,D2))
>
> The last term was already present in (1) and has already been
> expanded, so it can be omitted.  (That, in essence, is the
> meaning, for algebraic manipulations of this kind, of the rule
> permitting cyclic includes and specifying fixpoint semantics for
> them.) So we have
>
> (5) schema(D1) = builtins
>                  + immed(D1)
>                  + immed(override(O1,D2))
>                  + immed(override(O2,D1))
>
> which might be paraphrased as
>
> (5) schema(D1) = builtins
>                  + element elementA as decimal
>                  + element elementB as string
>                  + element elementA as string
>
> which is, as you correctly observe, not a legal schema.
>
> HTH
>
> --CMSMcQ
>
>
>
>
Received on Monday, 28 December 2009 18:46:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 December 2009 18:46:23 GMT