W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2006

[Bug 3527] Attributes: xml:id processing misleading

From: <bugzilla@wiggum.w3.org>
Date: Mon, 24 Jul 2006 13:54:25 +0000
To: public-qt-comments@w3.org
Message-Id: <E1G50t7-0004R9-EO@wiggum.w3.org>


           Summary: Attributes: xml:id processing misleading
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: frans.englich@telia.com
         QAContact: public-qt-comments@w3.org

The fifth step in Attributes reads:

If the attribute name is xml:id, the string value and typed value of the
attribute are further normalized by discarding any leading and trailing space
(#x20) characters, and by replacing sequences of space (#x20) characters by a
single space (#x20) character.
This step accomplishes xml:id processing as defined in [XML ID].

However, section 4 Processing xml:id Attributes in [XML ID] reads(among other

An xml:id processor must assure that the following constraints hold for all
xml:id attributes:
The normalized value of the attribute is an NCName according to the Namespaces
in XML Recommendation which has the same version as the document in which this
attribute occurs (NCName for XML 1.0, or NCName for XML 1.1).

This validation-part of xml:id processing is not mentioned in
Attributes. That is, I find it unclear what an implementation is supposed to do
on for example <elem xml:id="1.ThisIsNotAnNCName"/>

I can imagine several different ways: 1) issue an error; 2) the attribute is
ignored as if it wasn't set and/or is-id is not set; 3) set is-id to true and
keep the invalid value.

Perhaps related: this topic is also touched in F&O. 15.5.2 fn:id and 15.5.3
fn:idref reads:

"If any of the tokens is not a lexically valid IDREF (that is, if it is not
lexically an xs:NCName), it is ignored."

Received on Monday, 24 July 2006 13:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:13 UTC