Re: How to scope the note about D and override(E,D)

On Mar 14, 2011, at 12:26 PM, Henry S. Thompson wrote:
>>> ...
>> 
>> I don't see any appeal to component identity in the current
>> design.  At most there is an appeal to element equivalence.
> 
> I'm trying to avoid requiring the use of deep-equal as well, yes.

Thank you for clarifying.

Trying to avoid deep equality by appealing to an undefined
concept of source element identity, on the other hand, seems to
me to be a bad trade.  The XSD spec already spends too much
time trying to mandate particular optimizations instead of just
specifying what is required and leaving implementors to 
optimize. That's one reason it is so unnecessarily difficult to
read.

> 
>>> 
>>> O exploits this in two ways:
>>> 
>>> 1) If an override needs to be processed whose target has already been
>>>   processed with superset of the required markers, the override can
>>>   be ignored;
>> 
>> I think there are two problems with this behavior.
>> 
>> 1 If documents A and B each override C, with elements E1 and E2
>> respectively, and E1 and E2 provide declarations for type 
>> T (and nothing else), the rule you just stated suggests we can ignore
>> the override of C by B, if we saw A first.  And we can ignore the
>> override of C by A, if we saw B first.
> 
> Not so.  The markers will be
>  <'T','complexType',[A]/base-URI(),[A]//E1/complexType[@name='T']/position()>
> and 
>  <'T','complexType',[B]/base-URI(),[B]//E2/complexType[@name='T']/position()>
> respectively, which don't overlap at all, so no elimination is allowed.

Thanks for the clarification.  I think that if these are markers,
it might be better to avoid saying that

    Markers amount to SCDs for the _children_ of an override element. 

These appear to denote elements in infosets, not components;
SCDs denote components.  Saying that markers are like SCDs
gave me the impression that they would consist of (component-kind,
QName) pairs.

> 
>>> 
>>> 2) If a given schema document D is involved via more than one path of
>>>   overrides, actually constructing schema(D) can be done efficiently
>>>   by taking the union of all the markers which apply to it.
>> 
>> That suggests that if A and B each override C, with E1 providing a 
>> new declaration of type T1 and E2 providing a new declaration of T2,
>> then the result should be the same as if they agreed and both
>> E1 and E2 overrode both T1 and T2, in the same way.  
>> 
>> That would be a dramatic change from the status quo design, in 
>> which A is taken to want C's original declaration of T2 and B is
>> taken to want C's original declaration of T1.
> 
> Sure, in isolation, but the merger would only happen if some D had
> included both A and B.  

Yes, of course.  

> What I was describing is the construction of
> schema(R), for R the starting point of the whole exercise.  The only
> way A & B could both be involved is if they were both part of the
> target set of R, in which case we _do_ want both E1's override of T1
> and E2's override of T2 in the result.

Not me.  If A and B describe incompatible schemas and R
includes both of them, I want an error, not a WG's guess
about how I'd want to resolve the incompatibilities.

> 
>> I don't see the motivation for such a rule.
>> 
>> It's possible that the paraphrases you've just given glide over some
>> details of the algorithm and that the problems lie not in the algorithm
>> but in the paraphrases.
> 
> I don't think so -- I guess from this:
> 
>> Does this work in the general case?  I would expect that it would not
>> suffice to know that type T is being overridden, that it would be
>> necessary to know what the new definition is.
> 
> perhaps you read my reference to SCDs differently from the way I had
> intended -- at the very least I should have been clear that I meant
> _absolute_ SCDs.  Maybe the SCD analogy was unhelpful, insofar as we
> don't _have_ SCDs for the children of <override> elements, and perhaps
> we might end up saying we _can't_ have them.  

SCDs designate components, not elements.

Unless you propose to make override work on the component
level, the markers you want to construct will need to point to
source declarations (i.e. to elements), and XPath would be a 
simpler choice.

>> ...
> 
> Trees can certainly have leaves with duplicate labels.  

Of course they can.  

If that is what you mean, though, I can only suggest that it would
be easier on your readers to say it instead of saying something
else which is not what you mean.  

-- 
****************************************************************
* 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 19:22:44 UTC