This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.4.3 has the following example: <sml:key name="StudentIDisKey"> <sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/> <sml:field xpath="tns:ID"/> </sml:key> <sml:keyref name="CourseStudents" refer="tns:StudentIDisKey"> <sml:selector xpath="smlfn:deref( smlfn:deref(tns:Courses/tns:Course)/ tns:EnrolledStudents/tns:EnrolledStudent)"/> <sml:field xpath="tns:ID"/> </sml:keyref> Note that "selector" in <keyref> has 2 deref()s in it. The inner one gets to individual courses, and the outer one derefs to students. This mean that key and keyref select from the same set of elements. This of course makes the keyref *always* satisfied (ID of student A is the same as ID of student A). Note that key/keyref are normally used when element A refers to a different element B. Would this example be more illustrative if "EnrolledStudent" wasn't a reference but rather had an "ID" child, and the outer deref() was removed from the keyref selector? <sml:selector xpath="smlfn:deref(tns:Courses/tns:Course)/ tns:EnrolledStudents/tns:EnrolledStudent"/>
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. The keyref in this example models the constraints that all students who are enrolled in courses offered by a university are also enrolled in the university. Here's a simple instance that violates this constraint: University U has students S1, S2, ..., S1000 U offers courses C1, C2,..., C50 Students enrolled in C1 are S1, S2, S1001, S1002 (the last two are not enrolled in U)
> 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.
Resolution is to add a new example for key/keyref.
Created a new example for section 4.4.1 University Example. Updated section 4.4.3 sml:keyref. Sections are too long to repeat here.