W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2004

qnames and chameleon include

From: Biron,Paul V <Paul.V.Biron@kp.org>
Date: Tue, 21 Sep 2004 13:58:36 -0700
Message-Id: <8E9F0028F5955844899380433C60E39902A0D37E@cscrdemsg001.crdc.kp.org>
To: www-xml-schema-comments <www-xml-schema-comments@w3.org>
I just sat down to cross all my t's and dot all my i's in an explanation of why a certain implementation of chameleon include was buggy (and disagrees with every other implementation I've tried) when I realized that there may actually be an ambiguity in the LETTER of the rec which REQUIRES this buggy behavior.  Note: I won't mention which implemenation has the problem because that's not relevant to the question I'm asking.

Take the following 2 schema documents:

<!-- including.xsd -->
<xs:schema
		xmlns:xs='http://www.w3.org/2001/XMLSchema'
		targetNamespace='http://example.com'
		xmlns='http://example.com'
		elementFormDefault='qualified'>
<!-- note: target and default NS declared -->
   <xs:include schemaLocation='included.xsd'/>
   <xs:element name='root' type='foo'/>
</xs:schema>

<!-- included.xsd -->
<xs:schema
		xmlns:xs='http://www.w3.org/2001/XMLSchema'
		elementFormDefault='qualified'>
<!-- note: no target or default NS -->
	<xs:complexType name='bar'>
		<xs:attribute name='bif' use='required'/>
	</xs:complexType>
	<xs:complexType name='foo'>
		<xs:complexContent>
			<xs:extension base='bar'>
				<xs:attribute name='bof' use='required'/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
</xs:schema>

and the following instance doc:
<!-- root.xml -->
<root
	xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
	xsi:schemaLocation='http://example.com including.xsd'
	xmlns='http://example.com'
	bif='barf' bof='buf'/>

Most of the implementations that I've tried treat this chameleon include just fine...and everything works as expected.  However, one gets confused by the include and treats the definition of "foo" as invalid because it can't find the definition of "bar".

First, can the WG confirm that it's intention was for the above to be fine?  Assuming that it SHOULD be OK, I think I've found the spec underspecified in leading to that conclusion.

Trying to track down the relevant parts of the spec that cover this I found SRC: Inclusion Constraints and Semantics [1]:

	2 One of the following must be true:
	2.1 SII has a targetNamespace [attribute], and its
	 *actual value* is identical to the *actual value*
	 of the targetNamespace [attribute] of SII' (which must
	 have such an [attribute]).
	2.2 Neither SII nor SII' have a targetNamespace [attribute].
	2.3 SII has no targetNamespace [attribute] (but SII' does).

In this case, clause 2.3 is in force (where SII is included.xsd and SII' is including.xsd), which brings clause 3.2 into force:

	3.2 ... anywhere the *absent* target namespace name
	 would have appeared, the *actual value* of the
	 targetNamespace [attribute] of SII' is used.

Then we also need clauses 3&4 of SRC: QName resolution (Schema Document) [2]:

	3 its {target namespace} is identical to the
	 *namespace name* of the *QName*;
	4 its *namespace name* is either the target namespace
	 of the schema document containing the *QName* or that
	 schema document contains an <import> element information
	 item the *actual value* of whose namespace [attribute]
	 is identical to that *namespace name*. 

Strickly speaking, I believe this says that the base type of {http://example.com}foo is {}bar; however, in the combined schema there is no {}bar because it has become {http://example.com}bar and that is the error that is reported by the implementation in question.  If my analyis above is right then I believe the "buggy" implementation is actually operating according to the letter of the law and that an erratum needs to done to correct this.

Not wanting to walk too far down the "solution" path before fully understanding the problem to be solved, I can see at least 2 ways to fix this (maybe we need both, neither or something else completely, I'll leave that up the WG): 1) amend 3.2 of [1] to cover not only the absent *target* namespace but also the default namespace; 2) amend [2] and/or [3] (Qname resolution and/or interpretation) to somehow cover this case.

pvb

[1] http://www.w3.org/TR/xmlschema-1/#src-include
[2] http://www.w3.org/TR/xmlschema-1/#src-resolve
[3] http://www.w3.org/TR/xmlschema-1/#src-qname
Received on Tuesday, 21 September 2004 21:09:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:42 UTC