Re: vacuous and non-vacuous chains of override

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

C. M. Sperberg-McQueen writes:

> On Mar 11, 2011, at 10:47 AM, Henry S. Thompson wrote:
>
>>> ...
>> 
>> In this connection, rereading the status quo section 4.2.5 [1], I am
>> struck by a apparent (?) contradiction between the newly added text,
>> beginning "If the above definition is naively translated. . ."  (now
>> the first real Note after the override element tableau) and the _last_
>> (third) Note after the definition of *target set*, which appears to
>> _also_ be intended to address to the problem of circular chains of
>> overrides.
>> 
>> The latter appears to say that only vacuous chains, i.e. those with no
>> effective overriding children, are allowed.  
>
>
>
> This is the second in a series of three replies to Henry's message.
>
> Henry writes
>
>     The [note beginning "It is not forbidden for the schema document D
>     containing an <override> element E to be in the ·target set· of
>     E"] appears to say that only vacuous chains, i.e. those with no
>     effective overriding children, are allowed.
>
> For brevity, call this proposition P. This note discusses why I
> believe P to be false.
>
> First let's examine what the note says.
>
>     If applying the override transformation specified in
>     Transformation for xs:override (§F.2)to D and E results in a
>     schema document equivalent to D (e.g. when none of the[children]
>     of D, or of any <redefine> and <override> elements in D match any
>     of the[children] of E, except for the [children] of E themselves),
>     then the effect is the same as for a cyclic set of <include>
>     references, or as for multiple inclusions of the same document (as
>     described in the note at the end of Assembling a schema for a
>     single target namespace from multiple schema definition documents
>     (<include>) (§4.2.3)).
>
> The first reason to doubt P is superficial: A sentence of the form "If
> [condition] ... then the effect is the same as [situation]" does not,
> on the face of it, say anything at all about what is allowed and what
> is not allowed.  It only says that document graphs of a particular
> shape have the same effect as document graphs of another shape.

It's actually the _next_ paragraph I had in view:

  If applying the override transformation to D and E changes any of
  the XML representations of components, then the effect of D being in
  *target set* of E is the same as if two different schema documents
  containing conflicting definitions for the same components were
  included. ("As if" is inexact; in this case what happens is,
  precisely, that two schema documents with conflicting contents are
  included.)

> I don't see anything in the note that talks about things being allowed
> or not allowed.

Surely one is meant to read this as continuing "and we all know that
is an error".  It was the phrase "changes any of the XML
representations of components" which I read as meaning "any of E's
children are actually effective".  How do you read it?

> . . .
>
> Consider test 23, which is summarized using the algebraic notation
> introduced in section 4.2.1 of the XSD spec in the post [2]
>
> We have schema document A = over023.xsd and B = over023a.xsd.
>
>   A overrides B with E1 (which delares element doc as xsd:date).
>   B overrides A with E2 (which is vacuous).
>
> Imagine that we are starting with document A and seek to calculate
> schema(A).
>
> The target set of E1 includes

I think the _target set_ of E1 consists of B and A.

>   override(E1, B)
>   override(E2', A)
>   override(E1', B)

I agree that we get this for the contents of a synthetic schema
document determined by repeated applications of clause 3.1 of *Schema
Representation Constraint: Override Constraints and Semantics* [1]
starting with A, understanding the notation En' to refer to the
overlay of some incoming overlaying definitions and declarations on
the children of an overlay En.

> But note that because E2 is empty, E2' = E1,

Yes.

> and that E1' = E1.

I agree that's true, but how we know it's true seems to me to need
some further justification -- see my reply to your subsequent note.

> So another way to write the target set of E1 is
>
>   override(E1, B)
>   override(E1, A)
>
> Now the condition in the note is satisfied: override(E1, A) is
> equivalent to A.  And the situation is analogous to that described in
> the discussion of cyclic includes: the set of schema documents you
> have, which have a cycle, is equivalent to (calculates the same schema
> as) a similar set of schema documents in which the last link is
> missing.

Right, so it's OK for A to be in the target set of E1.

> But note that although the condition described in the note does apply,
> it is not the case that the override chain is vacuous: E1 contains a
> declaration (of element doc) which does override the corresponding
> declaration in document B.

[Note in passing we see at this point a more fundamental reason for
the answer to my earlier question of "Why is it Dold' and not Dold
which must correspond to a conforming schema document?", because Dold
== B does _not_ conform, as demonstrated immediately below, but Dold'
== override(E1, B) does, because the conflicting definition of <doc>
has been overriden]

I'm still unsure why the 3rd paragraph of the note, quoted above, does
_not_ apply in this case -- are we supposed to understand that it
means to only apply at the last step, not any of the intermediate
ones?  Relabelling the para to correspond to this example, we are
considering 

 If applying the override transformation to A and E1 changes any of
 the XML representations of components, then the effect of A being in
 target set of E1 is the same as if two different schema documents
 containing conflicting definitions for the same components were
 included.

So now I see my problem -- I was reading "applying the override
transformation to A and E1" as referring to the full impact of [1] on
schema A, whereas if we read it as just referring to the local outcome
of override(A,E1), which as noted above does figure in the overall
process, then indeed as observed above that does not "change any XML
representations" because it _is_ vacuous.

> If we start with B instead of A, and calculate schema(B), then we get
> a different result: the target set of E2 is
>
>   override(E2, A)
>   override(E1', B)
>
> The condition described in the note does not apply: override(E1',B) is
> not equivalent to B, and if we process both of them, then we end up
> with two conflicting declarations for doc, which is exactly what the
> third paragraph of the note is trying to say.  (Judging by your
> reaction, I gather that it is meeting with only imperfect success.)

As you may have seen, I was surprised to find that my algorithm [3]
came to the same conclusion.  But under the circumstances, I guess
that's reassuring.

> More on the general case of override chains in another note.

See reply to that in due course.

But this has already been very helpful.  I think at the very least
something like this, or your earlier more complete workthrough [2],
merits publication as a Note, if not as an appendix to the
spec. itself.

One final point - given what the Note under discussion says, perhaps
subject to some clarification and exemplification, does it really
help/make sense to also have the note we added further up, which tries
to say the same thing but more vaguely?

ht

[1] http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html#src-override
[2] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2011Feb/0014.html
[3] http://lists.w3.org/Archives/Public/www-xml-schema-comments/2011JanMar/att-0158/override_fix.html#xmpls
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFNfeoBkjnJixAXWBoRAqW8AJwOnDsjqhbfTx0G5nOCwOaaZYVWtgCeNhLS
S3k+Jps1xqGse+cvyERaw6w=
=7Jp5
-----END PGP SIGNATURE-----

Received on Monday, 14 March 2011 10:12:56 UTC