- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 07 Sep 2007 13:35:06 +0000
- To: public-sml@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5024 ------- Comment #2 from sandygao@ca.ibm.com 2007-09-07 13:35 ------- > It is incorrect to assume that the key and keyref in this example > will always select from the same set of elements and therefore the > keyref constraint is always satisfied. I agree that was over-simplification, but it is true in most cases. If for each student there is only one instance of StudentType, then at least for elements who do satisfy key/keyref constraints, the element selected by keyref is the same as the one selected by key. (Note that targetType of EnrolledStudent and that of Student are both StudentType.) But as I mentioned "key/keyref are normally used when element A refers to a different element B." What in the current example feels more like <xs:element name="e"> ... <xs:key name="key"> <xs:selector xpath="a/b"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref name="keyref" refer="key"> <xs:selector xpath=".//b"/> <xs:field xpath="@id"/> </xs:key> </xs:element> That is, key and keyref just use different ways to select the same set of "b" elements. But what we normally see is <xs:element name="e"> ... <xs:key name="key"> <xs:selector xpath="a/b"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref name="keyref" refer="key"> <xs:selector xpath=".//x"/> <xs:field xpath="@id"/> </xs:key> </xs:element> Then "x" elements refer to "b" elements via an "id" attribute.
Received on Friday, 7 September 2007 13:35:09 UTC