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 expression for $a in //@PRICE return rename $a as "COST" is currently defined to treat COST as a name in the default namespace for elements and types, despite the fact that it is clearly being used as an attribute name. Presumably the system is supposed to invent a namespace prefix, since the name clearly cannot be used unprefixed (or is this supposed to lead to a data model consistency error?) Either way, this seems likely to cause unwelcome surprises.
Michael, Would you like to suggest a way to fix this problem? --Don Chamberlin
My preferred solution would be to remove the option of supplying the new name as a string, and insist that it be supplied as a QName. We have a number of ways of getting a QName, including the xs:QName, fn:QName(), and fn:node-name() functions, and I think that allowing a simple string as a short-cut is not worth the ambiguities it creates. An alternative would be to interpret a string differently depending on whether the node being renamed is an element or an attribute.
The resolution of this bug should work for renaming PI's as well as attributes. I suggest that we revise Section 2.4.4 (Rename) by replacing Rules 2 and 3 with the following combined rule: 2. NewNameExpr must be a non-updating expression; otherwise a static error is raised [err:XUST0001]. NewNameExpr is processed as follows: a. If $target is an element node, let $QName be the result of evaluating NewNameExpr as though it were the name expression of a computed element constructor [XQuery Section 3.7.3.1]. If the namespace binding of $QName conflicts with any namespace binding in the "namespaces" property of $target, a dynamic error is raised [err:XUDY0023]. b. If $target is an attribute node, let $QName be the result of evaluating NewNameExpr as though it were the name expression of a computed attribute constructor [XQuery Section 3.7.3.2]. If the namespace binding of $QName conflicts with any namespace binding in the "namespaces" property of the parent (if any) of $target, a dynamic error is raised [err:XUDY0023]. c. If $target is a processing instruction node, let $NCName be the result of evaluating NewNameExpr as though it were the name expression of a computed processing instruction constructor [XQuery Section 3.7.3.5], and let $QName be defined as fn:QName((), $NCName). In addition to the above replacement, Rule 4 becomes Rule 3 and error code XUDY0025 is eliminated. Cheers, --Don Chamberlin
On 15 Jan 2008, the working group adopted the proposal in Comment #3. Michael, since you were present at the discussion, I am marking this bug report as Closed. --Don Chamberlin (for the working group)