5781 2008-06-22 14:18:17 +0000 identity constrailnt rules refer to 'node sets' - should be 'node sequences' 2009-04-20 22:07:13 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only Macintosh Mac System 9.x CLOSED FIXED resolved P2 normal CR 1 cmsmcq cmsmcq cmsmcq David_E3 www-xml-schema-comments oldest_to_newest 20724 0 cmsmcq 2008-06-22 14:18:17 +0000 The Validation Rule: Identity-Constraint Satisfied refers several times to 'node sets'. This phrasing is inherited from XSD 1.0, but makes no sense in an XPath 2.0 context. The rule should be revised to eliminate use of the term. (It might usefully be recast for clarity in addition.) 24667 1 cmsmcq 2009-04-13 00:26:59 +0000 A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5781.html (member-only link) 24683 2 sandygao 2009-04-13 15:57:25 +0000 I continue to believe that we should not use "sequence" in identity constraint discussions. I think the differences between "set" and "sequence" (no ordering; no duplicate) match better with identity constraints. XPath 2.0 moved to sequence for its own reasons. Have we examined that those reasons apply to identity constraints? Do we know that identity constraint works as expected if the "qualified node sequence" or "target node sequence" contains duplicates? (May not be possible given the current IDC xpath subset, but is that what we want to assume here?) Seems "unique" and "key" rules will always return "invalid" for duplicate items. The only change we really need seems to be from "all the {fields} evaluate to a node-set" to "all the {fields} evaluate to a node sequence". 24690 3 davep 2009-04-13 16:29:21 +0000 (In reply to comment #0) > The Validation Rule: Identity-Constraint Satisfied refers several times to > 'node sets'. This phrasing is inherited from XSD 1.0, but makes no sense > in an XPath 2.0 context. (In reply to comment #2) > I continue to believe that we should not use "sequence" in identity constraint > discussions. > The only change we really need seems to be from "all the {fields} evaluate to a > node-set" to "all the {fields} evaluate to a node sequence". As far as I can tell, this is the minimal change required for compatibility with XPath 2.0 . We do carefully acknowledge that XPath produces sequences, and then explicitly extract the set of terms/values/whatever-you-call-them in the sequence, so our definitions of assorted "sets" do not conflict. It would be better to recast the definition for clarity to eliminate the "is called", using the "the xxx is yyy" format as is used in the other three added or deleted definitions. 24696 4 davep 2009-04-13 17:23:26 +0000 (In reply to comment #3) > It would be better to recast the definition for clarity to eliminate the "is > called", using the "the xxx is yyy" format as is used in the other three added > or deleted definitions. Assuming Sandy's objection is upheld, I suggest that the definition of qualified node set be: "[Definition:] The qualified node set is that subset of the ·target node set· for which all the {fields} evaluate to a node sequence one of whose members is an element or attribute node with a ·non-absent· [schema actual value]." 24804 5 David_E3 2009-04-17 16:54:41 +0000 5781: identity constraint rules refer to 'node sets' - should be 'node sequences' http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5781.html Summary: issue requests that we align our terminology with QT's by saying 'sequence' not 'set'. There has been discussion; SG opposes most of the change. MSM's recommendation: fairly quick. - Amend the proposal by substituting 'set' for 'sequence' passim, EXCEPT in the phrase "nodes for which all the {fields} evaluate to a node sequence". Note that for the most part, this amounts to reverting the proposal. (It turns into a proposal for changing one instance of 'set' to 'sequence' and rephrasing a definition.) - Adopt as amended. 24868 6 sandygao 2009-04-20 21:23:46 +0000 During its 2009-04-17 telecon, the schema WG adopted the proposal in comment #5 to address this issue. With this change, the WG believes that the issue raised in this bug report is addressed. I'm marking this RESOLVED accordingly. Michael, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.