Re: pervasiveness of a redefine

On <import schemaLocation=".."> and for <xsi:schemaLocation> in an 
instance the schemalocations are definitely hints.   For example, the 
definition of <import> says[1]:

"The ·actual value· of the schemaLocation, if present, gives a hint as to 
where a serialization of a ·schema document· with declarations and 
definitions for that namespace (or none) may be found."

Reason:  there are a number of use cases in which it is important that 
processors be able to provide their own versions of schemas for particular 
namespaces, that the composition be controlled outside of the schema 
documents, or in the case of instances, that you don't trust the instance 
to name the schema (if you trusted the instance in an eCommerce scenario, 
why would you validate it?)

We consciously made <include> different, on the assumption that breaking 
the definition of a particular namespace into multiple files was likely to 
be done by one person or organization which would want some reliability in 
bringing those pieces together.  So, we don't say it's a hint.  However, I 
am not too thrilled with what we do say for <include>, which is [2]:

"The ·XML Schema· corresponding to <schema> contains not only the 
components corresponding to its definition and declaration [children], but 
also all the components of all the ·XML Schemas· corresponding to any 
<include>d schema documents. 

[...]

It is not an error for the ·actual value· of the schemaLocation 
[attribute] to fail to resolve it all, in which case no corresponding 
inclusion is performed. It is an error for it to resolve but the rest of 
clause 1 above to fail to be satisfied. Failure to resolve may well cause 
less than complete ·assessment· outcomes, of course. "

My reading is that this comes mighty close to being a roundabout way of 
saying it's a hint, as you can always claim that you were just 
sufficiently disconnected from the web that this or that URI didn't 
resolve.  I would have preferred to say "it's an error for the 
schemaLocation of an include not to resolve."

I am actually surprised to find that <redefine> is yet different, since I 
thought we had intended it to be completely parallel to include.  It is in 
most respects, but the second part of the quote above is not repeated for 
redefine.  Unless I'm missing something, we are silent on the implications 
of failure of schemaLocation to resolve for redefine.   Since we went to 
such trouble to say that it's not an error for <include> and not to say 
for the very similar <redefine>, one can almost make the case that the URI 
MUST resolve for <redefine>.  On the other hand, we don't quite say so.

At the very least, I think we should clarify the rules for redefine. 
Henry, if you agree, I think one of us should send a note to the comments 
list openning an issue.  Thank you.

Noah

[1] http://www.w3.org/TR/xmlschema-1/#composition-schemaImport

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








ht@inf.ed.ac.uk (Henry S. Thompson)
Sent by: xmlschema-dev-request@w3.org
03/29/2004 07:46 AM

 
        To:     "Michael Kay" <mhk@mhk.me.uk>
        cc:     "'James Taylor'" <JTaylor@nextance.com>, <xmlschema-dev@w3.org>, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: pervasiveness of a redefine



"Michael Kay" <mhk@mhk.me.uk> writes:

> # 
> # > Also, what is the "scope" of a redefine
> # 
> # Unbounded.
> # 
>
> OK, so what about:
>
> <a xsi:noNamespaceSchemaLocation="some.uri">
>   <b><c><d>
>     <a xsi:noNamespaceSchemaLocation="some.other.uri">
>
> where some.other.uri references a schema document that contains 
>
> <xs:redefine schemaLocation="some.uri">
>
> Which definitions are used to validate each of the two <a> elements?
>
> I expect the answer will be that these schema locations are only hints, 
so
> it's entirely implementation-defined: yes?

Yes, but the interesting question then obviously is "What if the
implementation respects the hints?".

Answer -- it's an error!  The REC protects you against this sort of
thing, in section 4.3.2 _How schema definitions are located on the Web_ 
[1]

 "4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation
     [attributes] can occur on any element. However, it is an error if
     such an attribute occurs after the first appearance of an element
     or attribute information item within an element information item
     initially *validated* whose [namespace name] it addresses."

ht

[1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/structures-with-errata.html#schema-loc
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of 
Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged 
spam]

Received on Monday, 29 March 2004 11:34:52 UTC