Re: Including schemas with no targetnamespace

Kohsuke KAWAGUCHI <kohsuke.kawaguchi@sun.com> writes:

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

Actually, the spec. does discuss this, in the section referred to in
the section Jeff quoted, namely [1], which does make sense of the
resolved/unresolved distinction.

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

That's addressed in the paragraph above where Jeff quoted, namely
clause 3.2 of [2]:

 "3.2 If [chameleon including], then the schema corresponding to the
 <include>d item's parent <schema> must include not only definitions
 or declarations corresponding to the appropriate members of its own
 [children], but also components identical to all the schema
 components of I, except that anywhere the absent target namespace
 name would have appeared, the actual value of the
 targetNamespace[attribute] of SII is used. In particular, it replaces
 absent in the following places:

  "3.2.1 The {target namespace} of named schema components, both at the
  top level and (in the case of nested type definitions and nested
  attribute and element declarations whose code was qualified) nested
  within definitions;

  "3.2.2 The {namespace constraint} of a wildcard, whether negated or
  not;"

> 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"/>

This defines {None}foo

>   <!-- include chameleon -->
>   <include schemaLocation="chameleon.xsd"/>

This turns {None}xyz into {urn:abc}xyz and its unresolved base
reference to {None}foo into a reference to {urn:abc}foo

>   <simpleType name="foo">  (2)
>     ...
>   </simpleType>

This defines {urn:abc}foo, which satisfies the above reference.

> </schema>
> 
> chameleon.xsd:
> <schema> <!-- no target namespace -->
>   
>   <simpleType name="xyz">
>     <restriction base="foo">    (3)
>       ...
>     </restriction>
>   </simpleType>
> </schema>

The reference to {None}foo is unresolved within this schema document.

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

I don't agree:  the specification of <include> semantics makes clear
that the dependency-based order of processing must be such that (3) is 
converted to components, then chameleon-included, which does the coercion.

[1] http://www.w3.org/TR/xmlschema-1/#conformance-missing
[2] http://www.w3.org/TR/xmlschema-1/#src-include
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Tuesday, 16 October 2001 05:58:42 UTC