28238 2015-03-19 09:51:13 +0000 [XDM 3.1] Lists that mix IDREF with non-IDREF values 2015-03-25 10:19:32 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Data Model 3.1 Last Call drafts PC All RESOLVED FIXED P2 normal --- 1 mike ndw public-qt-comments oldest_to_newest 118676 0 mike 2015-03-19 09:51:13 +0000 Sorry about this one: it's a tiny insignificant edge case... XDM states in section 6.3.4: <quote> is-idrefs If any of the atomic values in the typed-value of the attribute is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the is-idrefs property is true, otherwise it is false. Note: This rule means that a type constructed by list with an item type of xs:IDREF (or a type derived from xs:IDREF) has the is-idrefs property, whether or not the list type is named xs:IDREFS or is derived from xs:IDREFS. Because union types are allowed, it also means that an element or attribute with the is-idrefs property can contain atomic values of type xs:IDREF alongside values of other types. </quote> I have written a test case fn-idref-33 which uses a type list( union( NCName[pattern='[A-Z]'], IDREF ) ) and creates two elements with this type: <e>Q</e> and <e>Q some-id</e> I believe that with the rules as written, idref('Q') matches the second element but not the first. This is because the first element does not have the is-idrefs property, because the typed value does not include an atomic value of type IDREF. Clearly this behaviour is, to put it politely, counter-intuitive. (For the benefit of historians, the text was introduced as a result of bug #3032) I think there are two things we can do. (A) we can retain this interpretation of the spec, and explain it more clearly in the (cited) Note. (The Note is anyway incorrect in talking about is-idrefs as a property of a type, when it is actually a property of a node). (B) we can change the spec so that all elements whose type permits the type value to contain an atomic value of type IDREF have the is-idrefs property, whether or not the actual instance contains such a value. It would be an incompatible change, but it's very unlikely anyone would notice; we could claim that this is what we meant all along. 118905 1 mike 2015-03-24 16:03:25 +0000 We decided to go for (A) - no technical change to the spec, but explain the situation more clearly in notes in XDM and F+O. 118928 2 mike 2015-03-25 10:19:32 +0000 The non-normative Notes in F+O regarding this edge case have been clarified. Revised text for the Note in XDM has been proposed.