- From: Michael Kay <mike@saxonica.com>
- Date: Mon, 11 Feb 2008 21:35:38 -0000
- To: "'BANBURY David'" <David_BANBURY@rta.nsw.gov.au>, <xmlschema-dev@w3.org>
I think the problem here has very little to do with the key/keyref, and much more to do with namespaces. Unusually, you have not specified elementFormDefault="qualified" in your first schema. This means that the locally-declared elements Subset1, Subset2, and Element1 are in no namespace. This is reflected in your instance document, and in the fact that unprefixed names can be used to refer to these elements in the XPath expressions appearing in the key/keyref definitions. When you split your schema into two, the elements Subset1 and Subset2 have become global element declarations, which means they are now declaring elements in the target namespace of the schema. This means that this namespace must be used for these elements in the instance document, and it also means that the element name appearing in the path expression must be qualified with a prefix that is bound to this namespace. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of BANBURY David > Sent: 11 February 2008 08:12 > To: xmlschema-dev@w3.org > Subject: Keyref relationships in multi-file schemas > > > [Newbie posting; I apologise in advance for any poor etiquette] > > Before looking at the multi-file scenario, below is a sample > XML Schema describing the nested element structure. The key > aspects of the schema > are: > - The "Superset" root element contains 2 "Subsets". > - The Subsets contain "Elements" which have attributes. > - One Subset contains a key definition for its Element. > - The Superset element contains a keyref relating the > Elements from one Subset to the Elements in the other. > > Listing of SingleSchema.xsd: > <?xml version="1.0"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://a.b.c" xmlns="http://a.b.c"> > <xsd:element name="Superset"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="Subset1"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="Element1" > minOccurs="0" maxOccurs="unbounded"> > <xsd:complexType> > <xsd:attribute > name="PKField" use="required"/> > <xsd:attribute > name="FKField"/> > </xsd:complexType> > </xsd:element> > </xsd:sequence> > </xsd:complexType> > <xsd:key name="key_Subset1Element1"> > <xsd:selector xpath="./Element1"/> > <xsd:field xpath="@PKField"/> > </xsd:key> > </xsd:element> > <xsd:element name="Subset2"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="Element1" > minOccurs="0" maxOccurs="unbounded"> > <xsd:complexType> > <xsd:attribute > name="PKField" use="required"/> > <xsd:attribute > name="FKField"/> > </xsd:complexType> > </xsd:element> > </xsd:sequence> > </xsd:complexType> > </xsd:element> </xsd:sequence> > </xsd:complexType> > <xsd:keyref name="keyref_Superset_Sub2Elem1_Sub1Elem1" > refer="key_Subset1Element1"> > <xsd:selector xpath="Subset2/Element1"/> > <xsd:field xpath="@FKField"/> > </xsd:keyref> > </xsd:element> > </xsd:schema> > > > A corresponding data file might look like this: > > <?xml version="1.0"?> > <ns:Superset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://a.b.c SingleSchema.xsd" > xmlns:ns="http://a.b.c"> > <Subset1> > <Element1 PKField="111" FKField="-"/> > <Element1 PKField="112" FKField="-"/> > <Element1 PKField="113" FKField="-"/> > </Subset1> > <Subset2> > <Element1 PKField="211" FKField="111"/> > <Element1 PKField="212" FKField="112"/> > <Element1 PKField="213" FKField="113"/> > </Subset2> > </ns:Superset> > > > I appreciate the issues related to the differing scope of the > key and keyref but (in the terms of Bug 4076) the scope of > the keyref is wider than the scope of the key so I believe > this is valid. Microsoft's .NET Parser and MSXML seem to > disagree but Xalan, XSV and Saxonica approve. > > The problem arises when we split the schema placing the > Subset definitions into separate files. The Subset schemas > are then included into a Superset XSD file and accessed using > "ref" as shown in the 3 listings below. > > Listing of MultiSchemaSubset1.xsd: > <?xml version="1.0"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://a.b.c" xmlns="http://a.b.c"> > <xsd:include schemaLocation="./MultiSchemaSubset1.xsd"/> > <xsd:include schemaLocation="./MultiSchemaSubset2.xsd"/> > <xsd:element name="Superset"> > <xsd:complexType> > <xsd:sequence> > <xsd:element ref="Subset1" minOccurs="0"/> > <xsd:element ref="Subset2" minOccurs="0"/> > </xsd:sequence> > </xsd:complexType> > <xsd:keyref name="keyref_Superset_Sub2Elem1_Sub1Elem1" > refer="key_Subset1Element1"> > <xsd:selector xpath="Subset2/Element1"/> > <xsd:field xpath="@FKField"/> > </xsd:keyref> > </xsd:element> > </xsd:schema> > > Listing of MultiSchemaSubset2.xsd: > <?xml version="1.0"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://a.b.c" xmlns="http://a.b.c"> > <xsd:element name="Subset2"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="Element1" minOccurs="0" > maxOccurs="unbounded"> > <xsd:complexType> > <xsd:attribute name="PKField" use="required"/> > <xsd:attribute name="FKField"/> > </xsd:complexType> > </xsd:element> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > </xsd:schema> > > Listing of MultiSchema.xsd: > <?xml version="1.0"?> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://a.b.c" xmlns="http://a.b.c"> > <xsd:include schemaLocation="./MultiSchemaSubset1.xsd"/> > <xsd:include schemaLocation="./MultiSchemaSubset2.xsd"/> > <xsd:element name="Superset"> > <xsd:complexType> > <xsd:sequence> > <xsd:element ref="Subset1" minOccurs="0"/> > <xsd:element ref="Subset2" minOccurs="0"/> > </xsd:sequence> > </xsd:complexType> > <xsd:keyref name="keyref_Superset_Sub2Elem1_Sub1Elem1" > refer="key_Subset1Element1"> > <xsd:selector xpath="Subset2/Element1"/> > <xsd:field xpath="@FKField"/> > </xsd:keyref> > </xsd:element> > </xsd:schema> > > > I expected the data file to remain the same (except for the > xsi:schemaLocation) but in order to validate it was now > necessary to add namespace prefixes to the Subset1 & Subset2 > data elements. I have tried but been unable to avoid this > requirement; any advice gratefully accepted. > > However, the main problem is that the data file now validates > even if the keyref relationship is deliberately broken as shown below: > > <?xml version="1.0"?> > <ns:Superset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://a.b.c MultiSchema.xsd" > xmlns:ns="http://a.b.c"> > <ns:Subset1> > <Element1 PKField="111" FKField="-"/> > <Element1 PKField="112" FKField="-"/> > <Element1 PKField="113" FKField="-"/> > </ns:Subset1> > <ns:Subset2> > <Element1 PKField="211" FKField="119"/> > <Element1 PKField="212" FKField="112"/> > <Element1 PKField="213" FKField="113"/> > </ns:Subset2> > </ns:Superset> > > > This behaviour is reproduced by Xalan, XSV and Saxonica which > leads me to fear it is my XSD at fault but I can't see the > mistake. Again, any advice gratefully accepted. > > Regards, > David Banbury > > Traffic Systems Branch > Roads & Traffic Authority of NSW > > IMPORTANT NOTICE: This e-mail and any attachment to it are > intended only to be read or used by the named addressee. It > is confidential and may contain legally privileged > information. No confidentiality or privilege is waived or > lost by any mistaken transmission to you. The RTA is not > responsible for any unauthorised alterations to this e-mail > or attachment to it. Views expressed in this message are > those of the individual sender, and are not necessarily the > views of the RTA. If you receive this e-mail in error, please > immediately delete it from your system and notify the sender. > You must not disclose, copy or use any part of this e-mail if > you are not the intended recipient. > >
Received on Monday, 11 February 2008 21:35:57 UTC