- 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