5316 2007-12-11 14:24:38 +0000 [UPD] Rename: default namespace for attributes 2008-01-15 18:27:00 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Update Facility Last Call drafts PC Windows XP CLOSED FIXED P2 normal --- 1 mike andrew.eisenberg public-qt-comments oldest_to_newest 18037 0 mike 2007-12-11 14:24:38 +0000 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. 18115 1 chamberl 2007-12-17 18:38:42 +0000 Michael, Would you like to suggest a way to fix this problem? --Don Chamberlin 18116 2 mike 2007-12-17 18:51:04 +0000 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. 18292 3 chamberl 2008-01-14 23:10:43 +0000 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 18322 4 chamberl 2008-01-15 18:26:48 +0000 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)