This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1234 - [DM] Typed Value and String Value of QName-valued parentless attributes
Summary: [DM] Typed Value and String Value of QName-valued parentless attributes
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-10 22:31 UTC by Michael Kay
Modified: 2016-05-18 18:48 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2005-04-10 22:31:44 UTC
[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.
Comment 1 Norman Walsh 2005-04-19 15:24:17 UTC
Accepted at joint meeting 249
Comment 2 Michael Kay 2005-05-03 15:31:30 UTC
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.
Comment 3 PANCHO 2016-05-18 18:48:40 UTC
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.