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 1250 - [XQuery] the typed value of a document node
Summary: [XQuery] the typed value of a document node
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-04-14 18:50 UTC by Henry Luo
Modified: 2005-05-05 16:28 UTC (History)
0 users

See Also:


Description Henry Luo 2005-04-14 18:50:48 UTC
Under section 2.5.2 Typed Value and String Value
It is specified that For document nodes, the typed value of the node is the same
as its string value, which is the concatenating the string values of all its
descendant text nodes, in document order.

However, it might be more natural for the typed value for a document node to be
the same as the type value of the root element.
Since XML document can only one root element. That element contains all the
information that the document can have (except some comments).

In that way, the typed value of a document node still preserve the sequence of
atomic values. 

And when the user needs the concatenated string version, they can always use the
string value.
Comment 1 Michael Rys 2005-04-14 18:55:02 UTC
The following is my personal answer, based on the history of the current 

First, an XQuery document node can contain more than a single element node, 
and not every element node has a typed value. Thus it is better to keep the 
definition as is.
Comment 2 Henry Luo 2005-04-14 19:55:39 UTC
However, your answer has lead to another issue: 
Does the two XQuery expressions
fn:doc($uri as xs:string?) as document-node()?
document { expr }
return the same type of document node? 
If yes, then they should have same typed-value. 
If fn:doc returns a node tree, then should document { expr } also be typed as 
node tree?
And keeping document { expr } as node tree instead of string, 
has the benefit to enable the result document to be assigned to an variable,
and further processed by XQuery expressions like fn:doc.
Comment 3 Michael Kay 2005-04-14 20:12:11 UTC
The reason for the rule you refer to is backwards compatibility with XSLT 1.0.
Here it is very common for users to use constructs such as

<xsl:variable name="x">
[<xsl:value-of select="d"/>]

and then use $x as if it were a string.

Here the value of $x is a document node, which has a single text node child.
There is no root element. It's also common to see constructs like

<xsl:variable name="lookup">
<a code="12" value="red"/>
<a code="13" value="blue"/>
<a code="14" value="green"/>

where the document has several element nodes among its children.

Michael Kay
Comment 4 Michael Kay 2005-04-14 20:30:01 UTC
Responding to this question:

>Does the two XQuery expressions
>fn:doc($uri as xs:string?) as document-node()?
>document { expr }
>return the same type of document node? 

Yes, both expressions return a document node and the operations available on the
resulting document nodes are identical. In both cases, for example, you can use
a path expression $d//* to find all the element nodes within the document, and
in both cases you can use string($d) to get the string-value of the document
node, that is, the concatenation of its contained text nodes.

Michael Kay
Comment 5 Don Chamberlin 2005-04-18 15:55:40 UTC
Henry Luo, will you please indicate whether you are satisfied with the 
explanation provided by Michael Kay, or whether you are calling for a change to 
the XQuery specification?
Don Chamberlin
Comment 6 Henry Luo 2005-04-20 08:05:59 UTC
I'd like to rephrase here, and correct me if I'm wrong:
1. Schema type or data model for fn:doc or document {} are preserved as node 
tree, which is also used for path expression evaluation.
2. Typed value or atomized value is used, according to spec 2.4.2, for Function 
calls and returns. Does that mean when a $doc is passed into a function, it 
becomes concatenated string value? If that's the case, the node tree structure 
is lost, and what's the use of it in the function?

So i think, either the document should not be atomized when passed to a 
function and preserved as a complex type, or the typed value of document or 
complex typed element should be defined. 

Otherwise, how can a function receive a node tree as parameter, instead of just 
a sequence of atomic values?
Comment 7 Don Chamberlin 2005-04-20 16:31:52 UTC
Type-conversion of function arguments is governed by the expected type of the 
argument (that is, the type that was declared for the argument in the function 
signature). If the expected type is an atomic type, then atomization is 
performed when the function is called. If the expected type is a complex type, 
then no atomization is performed. Therefore, when a document node is passed to 
a function, it may or may not be atomized, depending on how the argument was 
declared in the function signature. These rules are explained in XQuery Section 
3.1.5, "Function Calls".

Henry, will you please let us know whether this explanation resolves your issue?
Comment 8 Don Chamberlin 2005-05-04 23:27:56 UTC
I believe that the questions raised by this comment have been answered and the 
comment can be closed. If you disagree, please reply before May 11, 2005.
--Don Chamberlin
Comment 9 Henry Luo 2005-05-05 01:39:51 UTC
Yes. I have no problem to close this issue.
Comment 10 Don Chamberlin 2005-05-05 16:28:19 UTC
Thanks, Henry!