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