[Bug 4519] [XDM] Definition of is-id property

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4519





------- Comment #4 from mike@saxonica.com  2007-07-31 18:16 -------
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.

Received on Tuesday, 31 July 2007 18:16:50 UTC