[Bug 28238] New: [XDM 3.1] Lists that mix IDREF with non-IDREF values

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28238

            Bug ID: 28238
           Summary: [XDM 3.1] Lists that mix IDREF with non-IDREF values
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Data Model 3.1
          Assignee: ndw@nwalsh.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 19 March 2015 09:51:14 UTC