This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[DM] Typed Value and String Value of QName-valued parentless attributes The Data Model states in 3.3.1.3: An implementation may choose to store the string-value only and derive the typed-value from it, or to store the typed-value only and derive the string-value from it, or to store both the string-value and the typed-value. There appears to be one case where the typed value of a node cannot be constructed from the string value. This is the case of a parentless attribute node whose type annotation is xs:QName or xs:NOTATION. A value-based implementation can represent such an attribute node by virtue of the triples proposal, but a string-based implementation cannot. To retain the feasibility of string-value-only implementations, I propose adding a new constraint to section 3.3.3 QNames and NOTATIONs: <quote> No qualified name that contains a prefix may be included in the typed value of an attribute node that has no parent. </quote> I believe that this constraint is already imposed by the XQuery language, which does not allow any way of creating a parentless attribute node that has a non-trivial type annotation. For XSLT, however, it prevents constructs of the form <xsl:variable name="x" as="attribute()"> <xsl:attribute name="a" type="xs:QName" select="'a:value'" xmlns:a="some.uri"/> </xsl:variable> XSLT will need a new error code indicating that this constraint is violated.
Accepted at joint meeting 249
A new error condition has been added to XSLT 2.0 (draft Y): Error XTTE1545 occurs if you try to validate a parentless attribute node against a type derived or constructed from xs:QName or xs:NOTATION.
The Data Model states in 3.3.1.3: An implementation may choose to store the string-value only and derive the typed-value from it, or to store the typed-value only and derive the string-value from it, or to store both the string-value and the typed-value. There appears to be one case where the typed value of a node cannot be constructed from the string value. This is the case of a parentless attribute node whose type annotation is xs:QName or xs:NOTATION. A value-based implementation can represent such an attribute node by virtue of the triples proposal, but a string-based implementation cannot. To retain the feasibility of string-value-only implementations, I propose adding a new constraint to section 3.3.3 QNames and NOTATIONs: <quote> No qualified name that contains a prefix may be included in the typed value of an attribute node that has no parent. </quote> I believe that this constraint is already imposed by the XQuery language, which does not allow any way of creating a parentless attribute node that has a non-trivial type annotation. For XSLT, however, it prevents constructs of the form <xsl:variable name="x" as="attribute()"> <xsl:attribute name="a" type="xs:QName" select="'a:value'" xmlns:a="some.uri"/> </xsl:variable> XSLT will need a new error code indicating that this constraint is violated.