This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.1.11.3 of the specification says that a processing instruction's name is set to the value of an object of type xs:QName. Since a processing instruction's name has a type of xs:NCName, at the very least the specification is missing some error handling if the given xs:QName has a namespace URI. Better still would be specific handling that obtained the new name for the PI as an xs:NCName.
Answering as an individual, I think that I'll give the same answer that I gave in bug 4171. The target property for a PI node is constrained in the Data Model to be an NCName. Section 3.2.2, upd:applyUpdates, Semantics, bullet 5, says: "If the resulting XDM instance violates any constraint specified in [XQuery/XPath Data Model (XDM)], a dynamic error is raised [err:XUDY0021]."
There is no president for converting an xs:QName to an xs:NCName in any of the XQuery specifications, and so I feel this needs to be discussed. Their are certainly two acceptable methods that I can think of: 1) Take the localname from the QName, and ignore the prefix and URI. 2) Take the localname from the QName, but raise an error if there is a prefix or URI present. You might also want to consider an xs:QName that hasn't got a prefix set, but has picked up a default namespace from somewhere.
I actually thought the reason for this rename operation taking a QName is that functions like fn:node-name() return xs:QNames. Even if that was not the reason, I think it would be a very good reason: do rename <?pi?> as node-name(<?pooh?>) should work.
John, Thanks for your comment, which was considered by the Query Working Group on Jan 29, 2007. We agree that XQuery should specify what happens when a rename expression attempts to give a PI node a QName with a non-empty prefix. The working group feels that this case should be treated as an error, and will define a new error code for this purpose. If you are satisfied with this resolution, please mark this bug report as "Closed." Regards, Don Chamberlin (for the Query Working Group)