This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The rules for the transform expression say (in 1a): "The source expression is evaluated as though it were an enclosed expression in an element constructor (see Rule 1e in Section 3.7.1.3 ContentXQ.)" However, Rule 1e only describes part of the processing of an enclosed expression in an element constructor. It's not clear whether the other parts of the processing are being expressly excluded. If the expression really were an enclosed expression in an element constructor, then a document node would be replaced by its children (rule 2) and adjacent text nodes would be merged (rule 3), and this would make a significant difference to the outcome. If it's only rule 1.e that is to be applied, then it's unreasonable to expect the reader to infer this from a parenthetical cross-reference. Also, 3.7.1.3 clause 1.e.ii.B refers to "the node constructed by this constructor", which makes no sense in this context. The parent property of a copied node should be set to null (or whatever euphemism for null we are using this week). It may be clearer to avoid the cross-reference to the XQuery 1.0 specification and extract the rules that actually apply in this case. ("as though" in specifications, like "may not", is a phrase that should always sound alarm bells). The same problem occurs in section 2.4.1 dealing with insert expressions. However, in this case I think it actually makes no difference to the final outcome whether rules 2 and 3 of the rules for enclosed expressions are applied or not.
Looking at this more carefully, given copy $e1 := $e2 (a) it seems to make little sense to allow $e2 to be anything other than a single node. Currently it is allowed to be a sequence of atomic values, which are strung together to form a text node, which is then modified. I can't believe this serves any useful requirement. Removing the ability for $e2 to be a sequence of atomic values would improve static type checking. With this change, it's only really 1.e.ii that's relevant. (b) within 1.e.ii, the following rules need to be amended: B: "the parent property is set to the node constructed by this constructor." D.II: "if copy-namespaces mode specifies inherit, the copied node inherits all the in-scope namespaces of the constructed node, " E: "When an element or processing instruction node is copied, its base-uri property is set to be the same as that of its new parent, "
I agree with Mike's Comment #1. Many of the rules for processing of element constructors do not apply to transforms. I suggest that we replace Transform Rules 1a and 1b with the following: (a) The source expression must be a non-updating expression; otherwise a static error is raised [err:XUST0001]. (b) The result of the source expression must be a single node [err:XUTY0013]. Let $node be this single node. (c) A new copy is made of $node and all nodes that have $node as an ancestor, collectively referred to as copied nodes. Each copied node receives a new node identity. The parent, children, and attributes properties of the copied nodes are set so as to preserve their inter-node relationships. Other properties of the copied nodes are determined as follows: (i) For a copied element node, the type-name property is set to xs:untyped, and the nilled, is-id, and is-idrefs properties are set to false. (ii) For a copied attribute node, the type-name property is set to xs:untypedAtomic and the is-idrefs property is set to false. The is-id property is set to true if the qualified name of the attribute node is xml:id; otherwise it is set to false. (iii) The string-value of each copied element and attribute node remains unchanged, and its typed-value becomes equal to its string-value as an instance of xs:untypedAtomic. Note: Implementations that store only the typed value of a node are required at this point to convert the typed value to a string form. (iv) All other properties of the copied nodes are preserved. (d) The variable name is bound to the top-level copied node generated in the previous step. The scope of this variable binding includes all subexpressions of the containing transform expression that appear after the variable binding clause, including the source expressions of later variable bindings, but it does not include the source expression to which the current variable name is bound.
One minor amendment to the proposal: I suggest that if copy-namespaces in the static context specifies no-copy, then in-scope namespaces should not be copied (unless they are actually used in element and attribute names, of course)
Mike's amendment in #c3 makes this consistent with: http://www.w3.org/TR/xquery/#id-content (D. The in-scope-namespaces property of a copied element node.) We should also want symmetry with the result of modifying the original in place and copying it over. We can't have symmetry both ways.
Michael, On 22 Jan 2008 the Query Working Group considered this issue and accepted the proposal in Comment #2 as amended by Comment #3. Since this decision is aligned with your suggestion, I am marking this bug as Closed. Don Chamberlin (for the Query Working Group)