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

```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 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:10 UTC