This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If the result of the target expression of "rename" has the wrong type, the following codes are defined: 1. If the result is an empty sequence, [err:XUDY0027] is raised. 2. If the result is non-empty and does not consist of a single element, attribute, or processing instruction node, [err:XUTY0012] is raised. (a) it's not clear why we need different codes for the two cases. As far as I'm aware, in all other contexts where a value of a particular type is required, we define a single code for all incorrect values. (The requirement to distinguish the two cases makes it difficult to reuse a type checking routine that only returns a success or failure result.) (b) it's not clear why the first case is a dynamic error and the second a type error. If anything, I would expect the reverse, since our usual SequenceType matching rules are perfectly adequate for detecting the first case, but inadequate for the second case since they don't allow union types. (But that hasn't stopped us from defining such things as type errors in the past, see for example the name expression of computed element constructors.)
Similar comments apply to the insert and rename expressions.
I meant, the problem affects insert, rename, and replace. Sorry about the noise.
Michael, The error codes you refer to were assigned by the working group in meeting 331 on 22 May 2007 as a resolution to Bug 4526. The submitter of Bug 4526 claimed that updating an empty sequence should be a dynamic error (not a type error) in order to make static typing implementations "usable". A history of this somewhat contentious issue can be found in the comments attached to Bug 4526. Regards, Don Chamberlin
Thanks for the history. I can see the logic, though I do not think that tweaks like this will ever make static typing "usable". It seems a shame that we are optimizing the design for static typing when so few people appear to be implementing it. From the perspective of a dynamic typing implementation (or one that does optimistic static typing) this case should clearly be a type error: it's logically no different to the type checking applied to the operands of the "to" operator. Personally I think the answer to this is to fix static typing so that cardinality errors are always handled optimistically - that is, it should only a static type error if you can prove that the cardinality is wrong, not simply because you can't prove that it's right. The vast majority of cases where apparently reasonable queries fail static type checking seem to fall into this category.
On 15 Jan 2008, the working group decided to close this bug report with no change to the specification, upholding its earlier resolution of related Bug 4526. Michael, since you were present at the discussion, I am marking this bug report as Closed. --Don Chamberlin (for the Query working group)