Re: vacuous and non-vacuous chains of override

On Mar 14, 2011, at 4:12 AM, Henry S. Thompson wrote:

> C. M. Sperberg-McQueen writes:

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

...

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

It certainly follows from the normative rules (and from the
observations made non-normatively in the note) that some
configurations of schema documents are in error. But the note only
points out that the schema documents in question have the same meaning
as other sets of documents.

If by "The [note] appears to say that ..." you meant only "It appears
to follow from the observations in the note that ..." (call this P'),
then I agree that my first reason for doubting P does not apply to P'.

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

Quite right, thank you for the correction. I should have said that the
target set of E1 is {A, B} and the transformation of overrides to
includes has as a consequence that the following schema documents are
all to be included in the schema being calculated.

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

> ...

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

I'm not sure what kind of justification you mean. It follows from the
definition of the override transform that if any E1 and E2 are
override elements in documents A and B respectively, and E2 has no
element children, then if the result of overriding B with E1 will be a
schema document containing an override element E2' with the same
schemaLocation as E2 and the same children as E1. It also follows from
the specification of the transform that if we override A with E2', the
result will have another override element with the same schemaLocation
as E1 and the same children as E2', which we have already established
are those of E1.

It's not a particularly difficult calculation, it seems to me. If
keeping track of corner cases like empty override elements is more
than a processor wants to do, then a simple comparison for
deep-equality on the appropriate pairs of children from the two
override elements ought to suffice. (Am I missing something?)


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

It's phrased in terms of document D containing override element E,
not in terms of any Di in the target set of E. And, yes, that's
because it is talking about a the specific case of that one document
and that one element.

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

But the chain is not vacuous: it does effectively override elements
in other schema documents.


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

I'm glad to think you find the algebraic notation helpful. If we were
ever to rework section 4 to make it clearer and to ensure that its
rules are sound, I think I'd agree that it might be useful to use this
notation more prominently in the specification.   But since we are 
going to have to leave section 4 substantially as is in any XSD 1.1, I
don't think adding an appendix is a good idea. 

I'm happy to contemplate drafting a Note on the topic, after
the WG as sent 1.1 to PR or Rec.  The design notes from January
2009, supplemented and revised in the light of the WG conversations
this month, would provide my first draft of the note.

Michael

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Monday, 14 March 2011 17:19:31 UTC