This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In schema, identity constraints are always scoped within an element (that corresponds to the element declaration with the IDC). Key/unique constraints are only checked within that scope; keyref constraints can only refer to keys in that scope. Is there analogous "scoping" for sml identity constraints? For example, can keyrefs in one instance document refer to keys in another instance document? If so, what if there are multiple occurrences of the same key constraint in other instance documents? How to tell which occurrence is used by the keyref?
Proposal: The scoping rules for SML identity constraints should be aligned with how they are defined for XML identity constraints. The referenced key should be located by walking the chain of ancestors (starting at self). The first such key found should be used for this purpose. This allows it resemble how primary-key/foreign-key relations are defined for databases.
I have added examples of id constraints with and without the proposed scope attribute below. They are based on the discussion in the "Proposal for allowing smlkeyref.doc" document. Example that uses the proposed 'scope' attribute. ------------------------------------------------- <element name="courses"> <sequence> <element name="students"/> <element name="student" maxOccurs="unbounded"> <sequence> <element name="ID"/> </sequence> </element> </sequence> <sml:keyref name="CourseStudents" refer="StudentIDisKeyRemote" scope="deref(students)"> <sml:selector xpath="course/student"/> <sml:field xpath="ID"/> </sml:keyref> </element> Example that achieves the intended goal without using the scope attribute. -------------------------------------------------------------------------- <element name="courses"> <sequence> <element name="students"/> <element name="student" maxOccurs="unbounded"> <sequence> <element name="ID"/> </sequence> </element> </sequence> <sml:keyref name="CourseStudents" refer="StudentIDisKeyLocal"> <sml:selector xpath="course/student"/> <sml:field xpath="ID"/> </sml:keyref> <sml:key name="StudentIDisKeyLocal" > <sml:selector xpath="deref(students)/student"/> <sml:field xpath="ID"/> </sml:key> </element>
In comment #1: > The referenced key should be located by walking the chain of ancestors > (starting at self). This is incorrect. In XSDL, keys "bubble up" to their ancestors. Keyrefs look at keys accumulated from the descendants.
There are a few reasons SML may choose to behave differently from XSDL. - XSDL was designed to stream well, which is part of the reason why keyrefs can only look at keys contained in the current sub-tree. Streamability can hardly be a requirement for SML. - XSDL only handles a single XML document; SML handles many XML documents. Comparing the 2 examples given in comment #2, there are a few differences: 1. Separation of concern In the "scope" approach, the reference only needs to identify where to look for keys; whereas the "ancestor" approach also requires the reference to know about how the keys are selected (<select>) and how the fields are identified (<field>). 2. Copies of the same/similar keys There may already exist an <xs:key> for the keys in the "students" document. In bug 4684, we decided that sml:keyref can't refer to xs:key. So an <sml:key> needs to be added, which is basically a copy of the <xs:key>. The example of the "ancestor" approach now requires that another similar (same fields but different selector) <sml:key> needs to be defined for *every* <sml:keyref> to these keys. This means that there may be n+2 similar key definitions for the same key concept: 1 for xs:key; 1 for sml:key; one for every <sml:keyref>. This increases maintenance cost. 3. Performance Because the "n" <sml:key>s (that are associated with <sml:keyref>s) are different key definitions, they will be evaluated separately, resulting the same key constraint being checked n+2 times. The "scope" approach can reuse keys produced by the single <sml:key>. I don't think we can deny the above 3 differences. They are advantages of the "scope" approach. Of course there's associated cost, which is the new "scope" attribute and semantics around it. The WG needs to weigh the benefit against the cost, and make an informed decision.
For discussion of scoping issue, see http://lists.w3.org/Archives/Public/public-sml/2007Oct/0257.html
Per our discussion on Nov 1, I think that SML should accommodate 2 scenarios: 1 - the desired sml:key is already available. Scoping reduces the proliferation of the same sml:key and achieves other benefits as in comment #4. 2 - the desired sml:key is not available. In this case, the sml:key can reside with the sml:keyref element as in comment #2, 2nd example.
Per consensus on 11/29