5664 2008-04-25 22:09:30 +0000 Should attribute xsi:type be an allowed field in an identity constraint 2008-05-09 16:17:44 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 unspecified PC Windows XP CLOSED WORKSFORME P2 normal --- 1 katrina.griffith cmsmcq www-xml-schema-comments oldest_to_newest 19946 0 katrina.griffith 2008-04-25 22:09:30 +0000 Would someone please clarify why the following unique constraint should not work? It seems to me that it should work and that this may be a bug. sample constraint: <xs:element name="ListNode" type="ListType" minOccurs="0"> <xs:unique name="Constraint1"> <xs:selector xpath="./Item"/> <xs:field xpath="@address"/> <xs:field xpath="@xsi:type"/> </xs:unique> </xs:element> In the sample xml that follows, I am expecting validation errors because more than one Item node of the same xsi:type share the same address value. sample xml: <RootNode xsi:noNamespaceSchemaLocation="TestSchema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ListNode> <Item xsi:type="SpecificItemType1" address="1" file="file1.xml" name="Item1"/> <Item xsi:type="SpecificItemType1" address="1" file="file2.xml" name="Item2"/> <Item xsi:type="SpecificItemType2" address="1" file="file3.xml" name="Item3"/> </ListNode> </RootNode> Here is the full schema representation. sample xsd: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cs="TestSchema.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:simpleType name="AddressType1"> <xs:restriction base="xs:int"> <xs:minInclusive value="1"/> <xs:maxInclusive value="254"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AddressType2"> <xs:restriction base="xs:int"> <xs:minInclusive value="0"/> <xs:maxInclusive value="655519"/> </xs:restriction> </xs:simpleType> <xs:complexType name="AListType"> <xs:sequence> <xs:element name="Item" type="AbstractItemType" minOccurs="0" maxOccurs="32"/> </xs:sequence> </xs:complexType> <xs:complexType name="AbstractItemType" abstract="true"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="file" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="SpecificItemType1"> <xs:complexContent> <xs:extension base="AbstractItemType"> <xs:attribute name="address" type="AddressType1" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="SpecificItemType2"> <xs:complexContent> <xs:extension base="AbstractItemType"> <xs:attribute name="address" type="AddressType2" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="RootNode"> <xs:complexType> <xs:sequence> <xs:element name="ListNode" type="AListType" minOccurs="0"> <xs:unique name="Constraint1"> <xs:selector xpath="./Item"/> <xs:field xpath="@address"/> <xs:field xpath="@xsi:type"/> </xs:unique> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 19947 1 mike 2008-04-25 22:29:32 +0000 Are you suggesting there is a bug in the W3C spec, or in some vendor's implementation of the spec? I can't see anything in the spec that says xsi:type is not allowed in a constraint, therefore it is allowed, therefore you should raise a bug against any implementation that doesn't allow it. 20064 2 cmsmcq 2008-05-09 16:12:09 +0000 On the XML Schema WG call today, we discussed this issue. We believe the analysis given in comment #1 is correct, and that if a processor rejects an identity constraint on the grounds that it involves xsi:type, then there is probably a bug in the processor. We therefore are closing the issue as WORKSFORME. This change to the record should cause email to be sent to the originator of the issue. Thank you for the comment; we hope that the clarification in comment #1 addresses your question. If you are happy with this resolution of the issue, please indicate so by changing the status of the issue to CLOSED. If you are unhappy with it, and want the WG to reconsider, you can so indicate by changing the status to REOPENED. If we don't hear from you in a reasonable amount of time (say two weeks), we'll assume you are content. Thank you again for your comment. 20065 3 katrina.griffith 2008-05-09 16:17:44 +0000 Thank you for answering my question. I needed to know that this was a valid construct before persuing the issue with my implementation provider.