This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems to me that a static typing regarding the transform expression is too strict and probably wrong. Specifically, the rule requires that the source expression for each copy variable have a static type of node() (i.e., exactly one node). If this rule were to be enforced, then the second example given in section 2.4.5 of the XQUF spec would fail. Furthermore, many of the transform tests in the XQUF test suite would fail as well. Finally, this rule is much stricter that the static typing rules of other updating expressions. For example, consider the target expression of a rename expression. It is a runtime error if this expression returns more than 1 node. However, its static type does not put any constraints on the cardinality. Why is transform different in this respect?
Personal response: The rule given in the prose (2.4.5, rule 1b) is "The result of evaluating the source expression must be a single node", and the error if it isn't is a type error. It's a principle of static typing that all type errors are detected statically. It's true that the second example query would fail static typing. The vast majority of queries that people write would fail static typing, but fortunately not many implementations enforce static typing. I think your comment amounts to saying that static typing creates significant usability problems, which is something the working group already knows. We all have different ideas for the solution to that problem, but making the required type of an expression in the static semantics looser than the rules for its dynamic type isn't one of them. Section 4.5.6 includes the analogous example insert node <x/> into //a which is a static type error because //a isn't known to return a single node. The absence of such a rule for "rename" would appear to be an oversight. This is also a type error, and with static typing enabled, potential type errors are always reported as static errors.
I don't think that the example insert node <x/> into //a would fail static typing, because the ST rule for the target expression of "insert into" is element*. In general, except for transform, the ST rules for all of the other updating expressions do not place a constraint on node cardinality. So, I was thinking that the transform rule may have a typo error: node() instead of node()*. In any case, a spec shouldn't include an example (like the one in 2.4.5) that contradicts the rules of the spec itself, right? So, either the transform ST rule should change, or the example in 2.4.5 (and several tests in the XQUF test suite as well) be fixed.
>In any case, a spec shouldn't include an example (like the one in 2.4.5) that contradicts the rules of the spec itself, right? There are many examples in the XQuery specification that fail static typing. Our usual approach is to add a note to that effect alongside the example. It would be unreasonable to require all examples to pass static typing, since most implementations do not support the feature, and most users can therefore use such example code without any trouble.
The static typing behavior of updates is consistent with the rest of the language, and we have no agreement to change it. I will add a NOTE to the document mentioning that the example does not pass static typing.
(In reply to comment #0) > > For example, consider the target expression of a rename > expression. It is a runtime error if this expression returns more than 1 node. > However, its static type does not put any constraints on the cardinality. Actually, the STA rule for RenameExpr requires that the TargetExpr's type have cardinality zero-or-one.
(In reply to comment #5) > (In reply to comment #0) > > > > For example, consider the target expression of a rename > > expression. It is a runtime error if this expression returns more than 1 node. > > However, its static type does not put any constraints on the cardinality. > > Actually, the STA rule for RenameExpr requires that the TargetExpr's type have > cardinality zero-or-one. > Yes, you are right. I was reading the rule wrong. The rule for rename has the line: statEnv |- Type1 <: (attribute *| element * | processing-instruction *)? I was interpreting the "*" as an occurrence indicator instead of a name wildcard. Sorry for the trouble.