RE: clarification of redefine semantics

Michael Kay writes:

>> The thing that's hopelessly inadequate in the current specs is that 
>> they suggest that you should process each schema document, 
>> derive a set of schema components, and then assemble the 
>> components as required by import/include/redefine. The fact is, 
>> you can't do that, because for example you can't decide what 
>> data type a fixed or default value is until all the components are 
>> available: which means you need to keep the original lexical 
>> value (and its namespace context, just in case it turns out to be a 
>> QName) until everything is known...

Yes.  Indeed, the current Rec goes further and in sections on <include> 
etc. applies the term "schema" to the (potentially incomplete or 
tentative) components that correspond to a single schema document.  That 
seems to me to contradict other parts of the Rec.  There is an ongoing 
debate in the schema WG as to how to apply the terminology moving forward. 
 Not only do we need to resolve the ambiguities you point out above, we 
need to adopt consistent terminology.  Either the term "schema" applies 
only to a collection of components that together meets the constraints on 
components and is usable for a validation (which is not true of what you 
get from a single schema document in isolation), or we need another term 
for such a collection.  My preference is to reserve the word "schema" for 
the set meeting the constraints and usable for validation;  others in the 
WG prefer the broader usage and refer to the narrower set as a "valid 
schema".  Either way is probably OK, but the recommendation is currently 
inconsistent.  Anyway, I agree that the ambiguity you point out is real, 
important and needs resolultion. 

>> So there's no way one can say the current specs are unambiguous in this 
area.
 
I only meant that the explicit statement that redefines are pervasive 
could be taken to trump the other ambiguities relating to other aspects of 
inclusion, etc.  I can see the other point of view.  Either way, a much 
effort is ongoing to clarify all of the above.  I strongly suspect that 
the clarification, however expressed, will make clear that redefines are 
resolved after all inclusions have been taken care of.  I also expect that 
explicit inclusions of the same document (address.xsd) will not cause an 
error.  There is some question as to whether it will be an error for 
seemingly identical components to be included from different documents. 
Stay tuned.  BTW:  there is not WG consensus on anything I've mentioned 
above, other than the need to clarify.  I'm just giving my best guess as 
to where things will land.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Michael Kay" <mike@saxonica.com>
Sent by: xmlschema-dev-request@w3.org
02/12/05 04:57 AM

 
        To:     "'James Taylor'" <JTaylor@nextance.com>, <xmlschema-dev@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: clarification of redefine semantics


 
 >  My reading of Schema 1.0 is that it's absolutely unambiguous that if the 
combined schema is accepted at all, the redefinition of Address   is  pervasive and applies throughout the schema that results from the 
transitive closure of the files referenced from Company.xsd. 
 
The thing that's hopelessly inadequate in the current specs is that they 
suggest that you should process each schema document, derive a set of 
schema components, and then assemble the components as required by 
import/include/redefine. The fact is, you can't do that, because for 
example you can't decide what data type a fixed or default value is until 
all the components are available: which means you need to keep the 
original lexical value (and its namespace context, just in case it turns 
out to be a QName) until everything is known (if indeed there *is* a time 
when everything is known!). There are other examples of this, for example 
the effect of xs:redefine depends on whether the XML representation 
specifies form="qualified", which is information that's only available in 
the XML representation and not in the component model.
 
So there's no way one can say the current specs are unambiguous in this 
area.
 
Michael Kay
http://www.saxonica.com/