This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
The following is my personal answer, based on the history of the current behaviour: 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.
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.
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"/>] </xsl:variable> 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"/> </xsl:variable> where the document has several element nodes among its children. Michael Kay
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
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? Thanks, Don Chamberlin
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?
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?
Henry, 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. Thanks, --Don Chamberlin
Yes. I have no problem to close this issue.
Thanks, Henry!