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 2.4.3.2 Replacing the Value of a Node states: "The expression following the keyword with must be a simple expression; otherwise a static error is raised [err:XUST0001]. This expression is evaluated as though it were an enclosed expression in an element constructor (see Rule 1e in Section 3.7.1.3 ContentXQ). Let $rlist be the node sequence that results from this evaluation. If $rlist contains a document node, the document node is replaced in $rlist by its children." However, in section 4.5.3 Replace, the text states "An element, text, comment, or processing instruction node can be replaced only by zero or more element, text, comment, or processing instruction nodes." statEnv |- Expr1 : Type1 statEnv |- Type1 <: (element * | text | comment | processing-instruction *)? statEnv |- Expr2 : Type2 statEnv |- Type2 <: (element * | text | comment | processing-instruction *)* ----------------------------------------------------------------------------- statEnv |- replace node Expr1 with Expr2 : empty This rule should instead be: statEnv |- Expr1 : Type1 statEnv |- Type1 <: (element * | text | comment | processing-instruction *)? statEnv |- Expr2 : Type2 statEnv |- Type2 <: (document | element * | text | comment | processing-instruction *)* ----------------------------------------------------------------------------- statEnv |- replace node Expr1 with Expr2 : empty because Expr2 may evaluate to a sequence including document nodes, but these document nodes are replaced by their children.
On a related note, the specification states that XUDY0027 is raised if the result of evaluating the target expression is an empty sequence. Why is this not a type error, and why do the static typing rules not prevent it?
Re your original point: No, the call to fs:item-sequence-to-node-sequence() introduced in the normalization rule ensures that the *core* replace expression (which is the one to which the static typing rules pertain) doesn't have to deal with document nodes. (The static type of the *argument* to fs:item-sequence-to-node-sequence() might involve the document node type. It also might involve atomic types. Those possibilities are handled by the static typing rules for that function.)
(In reply to comment #2) > Re your original point: No, the call to fs:item-sequence-to-node-sequence() > introduced in the normalization rule ensures that the *core* replace expression > (which is the one to which the static typing rules pertain) doesn't have to > deal with document nodes. > > (The static type of the *argument* to fs:item-sequence-to-node-sequence() might > involve the document node type. It also might involve atomic types. Those > possibilities are handled by the static typing rules for that function.) Ah, of course - thanks. I'd still like Comment #1 to be considered by the WG.
(In reply to comment #1) > On a related note, the specification states that XUDY0027 is raised if the > result of evaluating the target expression is an empty sequence. > > Why is this not a type error, and why do the static typing rules not prevent > it? Well, the static typing rules allow it because it's not a type error. As to why it's not a type error... this question was raised in the WG about a year ago: http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Apr/0108.html (member-only) It didn't get a definitive answer, but one person's recollection was that making it a type error would have been unusable under static typing.
Thanks. I'm happy to close the report as INVALID.