Proposal for resolving this issue:

Section 6.2.4, make the following changes:

is-id

  If the element is a complex type with element-only content, the
  is-id property is false. Otherwise, if any of the atomic values in
  the typed-value of the element is of type xs:ID, or a type derived
  from xs:ID, the is-id property is true, otherwise it is false.

is-idrefs

  If the element is a complex type with element-only content, the
  is-idrefs property is false. Otherwise, if any of the atomic values
  in the typed-value of the element 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.

In 3.3.1.3, replace the bulleted list with the following:

* Where union types occur, the implementation must be able to deliver
  the typed-value as an instance of the appropriate member type. For
  example, if the type an element node is my:integer-or-string, which
  is defined as a union of xs:integer and xs:string, and the
  string-value of the node is "47", the implementation must be able to
  deliver the typed-value of the node as either the integer 47 or the
  string "47", depending on which member type validated the element.

* Where types of xs:QName, xs:NOTATION, or types derived from one of
  these types occur, the implementation must be able to deliver the
  typed-value as a triple including a local name, a namespace prefix,
  and a namespace URI, even though the namespace URI is not part of
  the string-value (see 3.3.3 QNames and NOTATIONS).

This seems a radical change: it means that we set the is-id property on an element (but not an attribute) that has a list type with an item type of xs:ID, or a union type with a member type of xs:ID. Is that what you intended, and if so, could you explain why?

I overlooked the fact that I hadn't made the equivalent change in the attribute case.

Trying to craft a resolution to this issue, I looked around at what's in XDM and concluded that we were going to have to look at the typed-values of elements and attributes.

The fact that we have to look at the typed-value (instead of the type-name) means that we have to look explicitly at the types of the members of the list of atomic values that comprise the typed-value.

So what do we do if the list contains more than one element?

1. is-id is true if any of the values is of type xs:ID (or derived from)
2. is-id is true if the first value is of type xs:ID (or derived from)
3. is-id is false

I think 1 is the choice of least surprise to users. I could live with 3. I think 2 is wrong.

Another option is:

for is-id: if the typed value contains exactly one item, and that item is an instance of xs:ID, then set the is-ID property. (There's not much point in setting the property if the value contains no items or more than one item, as id() will never retrieve it anyway).

for is-idref: OK as written, but applying it to both elements and attributes.

I actually think this rule is an improvement: it means that you can create a subtype of xs:IDREF and then construct a list whose items belong to this subtype, and this list will now be treated in the same way as an xs:IDREFS, which was not previously the case. But I'm a little bit concerned that the full implications need some careful thought.

Mike's rule works for me.

Fixed in CVS.