This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This relates to attribute constructors for the xml:id attribute within a direct element constructor. List item 5 in 3.7.1.1 reads: If the attribute name is in namespace http://www.w3.org/XML/1998/namespace and its local part is id (informally, if the attribute name is xml:id), the string-value of the attribute must be in the lexical space of the type xs:NCName [err:XQST0082], and the is-id property of the resulting attribute node is set to true; otherwise the is-id property is set to false. In general it's not known until run-time whether the value of the attribute is a valid NCName, so this should be a dynamic error not a static error. Michael Kay
Also affects 3.7.3.2 Computed Attribute Constructors
I also note that XSLT explicitly says there are no constraints on the value of an xml:id attribute, whereas XQuery says it's an error if it isn't an NCName. I can't see any good reason why the two specs should be different. I think the XSLT decision was made on the basis that invalid values should only be an error if you are validating. Michael Kay
At the July 2005 F2F, Don Chamberlin observed that this bug is a duplicate of #1570. *** This bug has been marked as a duplicate of 1570 ***