I think we should make the two situations consistent. I'm inclined to say that we should be more liberal in attributes rather than less liberal in elements, but I don't feel strongly about it.

I think we need to make sure that anything we adopt is consistent with XML Schema. I believe XML Schema also has open issues about the uniqueness constraints applied to types constructed from xs:ID by list or union; we probably need to solve this one together.

Update from XML Schema WG.

Schema 1.0 has the following rules about id-ness:
- only nodes *declared* with type ID or types derived from it (by extension/restriction) are viewed as ID values
- only nodes *declared* with type IDREF or types derived from it (by extension/restriction) are viewed as IDREF values
- only nodes *declared* with type IDREFS or types derived from it (by extension/restriction) are viewed as IDREFS values

All other cases (ID/IDREF/IDREFS appear in a union; user defined list of IDREF; ...) are *not* viewed as ID/IDREF values.

Schema 1.1 changed the above situation  (as part of fixing bug 2041):
- For every atomic *actual value* (may be a member in a list value) whose type is ID or a type derived (restriction/extension) from it, it's an ID value.
- For every atomic *actual value* (may be a member in a list value) whose type is IDREF or a type derived (restriction/extension) from it, it's an IDREF value.

My proposal to fix this is as follows. The proposal is designed to minimize the amount of change while still making the spec coherent and aligning it as far as possible with the XML Schema 1.1 direction, and adding non-normative notes to clarify the effect. The only substantive change is to align the rules for constructing attributes from the PSVI with the rules for elements.

(a) For the is-id property in an element node created from the PSVI, retain the current rule in J.3 (but fixing a typo marked **):

If the element has a complex type with element-only content, the is-id property is false. Otherwise, if the typed-value of the element consists of exactly one atomic value *and* that value is of type xs:ID, or a type derived from xs:ID, the is-id property is true, otherwise it is false.

Add two Notes:

Note 1: this means that in the case of a type constructed by list from xs:ID, the ID is recognized provided that the list is of length one. A type constructed as a union involving xs:ID is recognized provided the actual value is of type xs:ID. The uniqueness semantics of types constructed by list or union from xs:ID are unclear in the current edition of XML Schema 1.0.

Note 2: the element that is marked with the is-id property, and which will therefore be retrieved by the fn:id function, is the node whose typed value contains the xs:ID value. This node is a child of the element node that, according to XML Schema, is uniquely identified by this ID.

(b) Bring the rules for the is-id property of attribute nodes constructed from a PSVI into line with the rules for elements. Changes marked **:

    If the attribute is named xml:id and its [attribute type] property does not have the value xs:ID *or a typed derived from xs:ID*, then [xml:id] processing is performed. This will assure that the value does have the type xs:ID and that it is properly normalized. If an error is encountered during xml:id processing, an implementation may raise a dynamic error. The is-id property is always true for attributes named xml:id.

*Otherwise, if the typed-value of the attribute consists of exactly one atomic value and that value is of type xs:ID, or a type derived from xs:ID, the is-id property is true, otherwise it is false.*

Note 1 above for elements also applies here.
  
In construction from a PSVI, there is no change to the rules for the is-idref property for element and attribute nodes, except for a Note:

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-idref 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-idref property can contain atomic values of type xs:IDREF alongside values of other types.

No change to the rules for mapping from an Infoset.

In Functions and Operators:

Section 15.5.2, change the Note:

Note: If the data model is constructed from a PSVI, an element or attribute will have the is-id property if its schema-defined type is xs:ID or a type derived by restriction from xs:ID.

to read:

Note: If the data model is constructed from a PSVI, an element or attribute will have the is-id property if its typed value is a single atomic value of type xs:ID or a type derived by restriction from xs:ID.

Section 15.5.3, fn:idref, add another para to the notes:

If the data model is constructed from a PSVI, the typed value of a node that has the is-idref property will contain at least one atomic value of type xs:IDREF (or a type derived by restriction from xs:IDREF). It may also contain atomic values of other types. These atomic values are treated as candidate IDs if their lexical form is valid as an xs:NCName, and they are ignored otherwise.

In a recent call, I expressed some reservations about the interpretation of 
XSDL 1.0 reflected in comment #3.  It's correct that XSDL 1.0 Structures
treats values as IDs (by enforcing the relevant uniquness constraint) if
and only if their type is ID "or derived from ID".   And it's true that
in XSDL 1.1, the term "derived from" is used of simple types only to cover
restriction, not the list or union constructions.  But in XSDL 1.0 Structures,
the term "derived" is not formally defined as a term, and in 1.0 Datatypes
it is used both for derivation by restriction and for construction by list
and union.  (IDREFS, for example, is described as being "derived from" IDREF.)

So in principle, at least, it's possible to argue that 1.0 Structures should
be read as attributing ID-hood, IDREF-hood, and IDREFS-hood, respectively,
to lists whose item types are ID, IDREF, or IDREFS, and also to unions which
have ID, IDREF, or IDREFS as member types.

The rules for constructing the ID/IDREF table, however, lead to unexpected
and implausible results if given this interpretation.  If type T1, defined 
as list of ID, is treated as having ID-ness, then if the list "a b c" is
encountered in the document with type T1, the ID/IDREF table gets an entry
for the list "a b c", NOT for the individual items a, b, and c.  And if
type T2 is a union of int and ID, then any value of the union would get an
entry in the table, not just the IDs.  These consequences persuade me
that in the relevant passages "derived from" means only derived by 
simple type restriction or derived by extending a simple type to form a
complex type with simple content.

So the skepticism I expressed on the call appears to have been misplaced;
the interpretation of XSDL 1.0 offered in comment #3 seems the only
plausible one.

This is now covered by erratum DM.E005 for the data model, and FO.E13 for Functions and Operators, and is accordingly marked as FIXED. This closes action A-341-04.