- From: Kohsuke KAWAGUCHI <kohsuke.kawaguchi@sun.com>
- Date: Mon, 15 Oct 2001 13:35:37 -0700
- To: Jeff Lowery <jlowery@scenicsoft.com>, xmlschema-dev@w3.org
Thanks for the info. But I don't think this is a problem that can be fixed by such an easy "errata." Firstly, the spec does not define when an (uri,local) pair is resolved to a component. The phrase "QName values for such (unresolved) references" is meaningless unless we define when the resolution is done. Also, the spec does not define the order of processing. The words "resolved" and "unresolved" do not make sense unless that definition. Secondly, that note takes care of "unresolved references" only. This should (or "must" :-P ) mean that the namespace URI is not modified if the reference is resolved properly. ??? Consider the following example. foo.xsd: <schema> <!-- no target namespace --> <simpleType name="foo"> (1) ... </simpleType> </schema> hub.xsd: <schema targetNamespace="urn:abc"> <!-- import foo as itself. this doesn't have chameleon effect --> <import schemaLocation="foo.xsd"/> <!-- include chameleon --> <include schemaLocation="chameleon.xsd"/> <simpleType name="foo"> (2) ... </simpleType> </schema> chameleon.xsd: <schema> <!-- no target namespace --> <simpleType name="xyz"> <restriction base="foo"> (3) ... </restriction> </simpleType> </schema> Assume that the processor handles schema in the order of SAX, and assume that the resolution is done when the QName is seen. Now when (3) is processed, there is a live (absent,"foo") component (1). The current wording is broken if we want (3) to refer to (2). regards, -- Kohsuke KAWAGUCHI +1 650 786 0721 Sun Microsystems kohsuke.kawaguchi@sun.com
Received on Monday, 15 October 2001 16:35:39 UTC