W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2002

Re: referencing wildcard content

From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
Date: 18 Nov 2002 19:11:44 +0000
To: Stefan Wachter <Stefan.Wachter@gmx.de>
Cc: xmlschema-dev@w3.org
Message-ID: <f5bsmxylmkv.fsf@erasmus.inf.ed.ac.uk>

Stefan Wachter <Stefan.Wachter@gmx.de> writes:

> Hi all.
> 
> According to a recent discussion in this list on the equality of values I
> think that the test case idc006.nogen.v00 of the SUN schema test suite is
> incorrect. The test case consists of the following instance and schema document:
> 
> instance:
> 
> <root xmlns="http://www.publishing.org">
> 	<keys>
> 		<a>
> 			<a>
> 				<b id="id1">
> 					<b id="id2" />
> 				</b>
> 			</a>
> 		</a>
> 	</keys>
> 	<keyref>id1</keyref>
> 	<keyref>id2</keyref>
> </root>
> 
> schema:
> 
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> 		targetNamespace="http://www.publishing.org"
> 		xmlns="http://www.publishing.org"
> 		xmlns:x="http://www.publishing.org"
> 		elementFormDefault="qualified">
> 	
> 	<xsd:element name="root">
> 		<xsd:complexType>
> 			<xsd:sequence>
> 				<!-- define keys in this element -->
> 				<xsd:element name="keys">
> 					<xsd:complexType>
> 						<xsd:sequence>
> 							<xsd:any processContents="skip" maxOccurs="unbounded" />
> 						</xsd:sequence>
> 					</xsd:complexType>
> 				</xsd:element>
> 				
> 				<!-- define keyrefs in this element -->
> 				<xsd:element name="keyref" maxOccurs="unbounded" minOccurs="0"
> type="xsd:string" />
> 			</xsd:sequence>
> 		</xsd:complexType>
> 		
> 		<!-- corrected: no default namespace in XPath -->
> 		<xsd:key name="trickyKey">
> 			<xsd:selector xpath=".//x:keys/x:a/*/x:b|.//x:keys/x:a/*/*/x:b" />
> 			<xsd:field    xpath="@id" />
> 		</xsd:key>
> 		
> 		<xsd:keyref name="trickeyRef" refer="trickyKey">
> 			<xsd:selector xpath=".//x:keyref|.//x:keyref|./x:keyref|./x:keyref" />
> 			<!-- should be considered equal to "." -->
> 			<xsd:field    xpath=".|.|." />
> 		</xsd:keyref>
> 		
> 	</xsd:element>
> </xsd:schema>
> 
> To summarize: The "keys" element of the instance document is indexed
> two times using the two "id" attributes of the nested "b"
> elements.

No, two different 'b' elements are indexed within the scope of a
single 'root' element, each by their @id.

> No type info is available for the "id" attributes. Therefore the
> "anySimpleType" should be assumed. (?)

Yes, attrs with no specified type definition default at
component-construction time to anySimpleType.

> The "keyref" elements are of type string. A value of type string can never
> be equal to a value of type "anySimpleType". Therefore the keyref constraint
> is not satisfied.

Equality testing against anySimpleType is not defined in the spec.  An
erratum acknowledging this but _not_ fixing it at this time is about
to be published.  Accordingly, alas, processors are free to accept
_or_ reject this document.

Workaround: _always_ give your keys explicit type definitions.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, 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/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Monday, 18 November 2002 14:11:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:35 GMT