[Bug 1234] [DM] Typed Value and String Value of QName-valued parentless attributes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=1234

PANCHO <BRANSTORM_69Q@HOTMAIL.COM> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |BRANSTORM_69Q@HOTMAIL.COM

--- Comment #3 from PANCHO <BRANSTORM_69Q@HOTMAIL.COM> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 18 May 2016 18:48:44 UTC