This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section http://www.w3.org/TR/xquery-update-10/#id-update-typing-transform, the static typing rules is specified for transform expression in XQUF. However, the rule appears to be have following issues: Consider transform expression copy $var := expr modify .... (: some modification on $var ::) return $var The semantics of transform expression is that when modify expression is being evaluated, the $var's value is not changed, however, when evaluating the return expression, the $var's value is changed from the modify expression (that is, snapshot ends and PUL is applied). Thus when we do static type analysis for modify expression, the $var's static type shall be different from the static type of $var when do static type analysis for return expression. Such type distinction before and after modifcation does not appear to be reflected in the XQUF static type analysis rule. That is the statEnv for all the copied variables needs to be recomputed after analysis of the modify expression before evaluating the return expression. Of course, to make static type analysis easier but sound, the type analysis can assign each variable's static type as node() after modification is applied.
Andrew further notices the following bug in transform expression static typing rule: I may be seeing a different problem here. In section 2.4.5 Transform, rule 1)c)i and ii, we say: i) For a copied element node, the type-name property is set to xs:untyped, and the nilled, is-id, and is-idrefs properties are set to false. ii) For a copied attribute node, the type-name property is set to xs:untypedAtomic and the is-idrefs property is set to false. The is-id property is set to true if the qualified name of the attribute node is xml:id; otherwise it is set to false. In the modify clause, we could infer a static type for each copy variable of something like element(*, xs:untyped), attribute(*, xs:untypedAtomic), or just node()? As the copied nodes can be replaced in the modify clause, we should infer only node()* for these variables in the return clause. -- Andrew
Andrew said: > As the copied nodes can be replaced in the modify clause, we should > infer only node()* for these variables in the return clause. I disagree. Although you can replace copied nodes, you can't replace the node that a TransformExpr-variable is bound to, because it doesn't have a parent. (And even if you *could*, the variable would stay bound to the node, not the replacement.) So, to resolve this issue, I propose that in the rule in question, in the two premises of the form: statEnvi = statEnvi-1 + varType(Variablei => Typei) we change the "Typei" to [[ node() ]]_sequencetype That is, the static type of each variable (thoughout its scope) is node().
yes, node() as I stated in the bug description.
At its meeting this morning, the XQuery WG accepted the proposal in comment #2, and I have accordingly edited the sources for the Update spec. Consequently, I'm marking this issue resolved-FIXED. If this resolves the issue to your satisfaction, please mark it CLOSED.