Re: Default namespaces and <includes>

"Aung Aung" <aaung@microsoft.com> writes:

> Thanks for the quick response. Forgive me for persisting with this, I am
> not sure your answer my quesetion, maybe my question is not clear, I
> will attempt to make it clearer below. I have 2 issues below. (A). the
> existing issue and (B). a new question raised from the existing issue.
> 
> Issue (A): I am confused....I do now see anywhere in the XSD spec that
> allows such inheritance of namespace declaration from includer XSD to
> includee XSD.

Clauses 2.3 and 3.2 of Inclusion Constraint Semantics [1] provide for
the so-called 'chameleon' include.

> Lets put a prefix for the namespace declaration in a.xsd.

This can _never_ make any difference -- each schema document is
interpreted per the prefixing/qualification rules, and the resulting
expanded names (which we write for illustration as {ns or None}local)
are the basis for all further computation.

> Should the following still valid?

> a.xsd~~~~~~~~~~ the targetNamespace 'foo' is used to qualified all the
> global element and attributes in the including and includee XSD(s).
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
> 	targetNamespace="foo" 
> 	xmlns:a="foo">

Note the above declaration is irrelevant and serves no purpose, as
there are no a: prefixed names in this document

>    <xsd:include schemaLocation="b.xsd" />
>    <xsd:include schemaLocation="c.xsd" />
> </xsd:schema>



> b.xsd~~~~~~~~~~~ Which one of the following XSD is valid for a.xsd? 
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>    <xsd:element name="foo" type="foo"/>
> </xsd:schema>
> 
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> 	xmlns:a="foo">
>    <xsd:element name="foo" type="a:foo"/>
> </xsd:schema>
> 
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>    <xsd:element name="foo" type="a:foo"/>
> </xsd:schema>

This is broken, because there is no binding for the 'a' prefix.
The other two are OK, although the second is odd, in that it works
_only_ because it and c.xsd are being included into a schema with
target namespace 'foo' -- if included in a schema doc't with any
_other_ target namespace, this will not work, because {foo}:foo will
_not_ be converted.

> c.xsd~~~~~~~~~~~ the type 'foo' will be converted to [foo]:foo
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>  <xsd:simpleType name="foo">
>   <xsd:restriction base="xsd:string">
>    <xsd:enumeration value="test"/>
>   </xsd:restriction>
>  </xsd:simpleType>
> </xsd:schema>
> 
> 
> Issue (B). in light of this issue we are discussing, there is another
> issue been raised by Derek...
> In XSD spec 4.2.1 said the following:
> Schema Representation Constraint: Inclusion Constraints and Semantics 
> 
> In addition to the conditions imposed on <include> element information
> items by the schema for schemas, all of the following must be true:
> 1 If the *actual value* of the schemaLocation [attribute] successfully
> resolves one of the following must be true:
>   1.1 It resolves to (a fragment of) a resource which is an XML document
> (of type application/xml or text/xml with an XML declaration for
> preference, but this is not required), which in turn corresponds to a
> <schema> element information item in a well-formed information set,
> which in turn corresponds to a valid schema. 
>   1.2 It resolves to a <schema> element information item in a
> well-formed information set, which in turn corresponds to a valid
> schema. 
> 
> Reading from it, the b.xsd from my example which is included in the
> a.xsd is NOT allowed, it does not have a well-formed information set
> which in turn corresponds to a valid schema. 
>  <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>     <xsd:element name="foo" type="foo"/>
>  </xsd:schema>

This is a perfectly well-formed XML document, so it has an information 
set.  It also corresponds to a well-formed schema.  It has a dangling
reference, but that's explicitly allowed for.

> Should it work? Where is the type="foo" resolved to? Doesn't b.xsd also
> needs to explicitly have <include schemaLocation="c.xsd"/> ?

Remember that references are explictly lazy, that is, dangling
references are not an error until they _need_ to be resolved because
some aspect of an _instance_ being validated requires them.

ht

[1] 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 Friday, 28 September 2001 03:28:34 UTC