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 Bug 5672, it was clarified that treat as can be evaluated lazily. I'm fairly sure that the input of a typeswitch expression _can't_ be evaluated lazily, yet treat as is specified in FS to be normalized to a typeswitch expression: [Expr treat as SequenceType]Expr == typeswitch ([ Expr ]Expr) case $fs:new as SequenceType return $fs:new default $fs:new return fn:error() Is this normalization rule correct? With the function: declare function local:items() { (1, 2, 3, "four") }; consider: (local:items() treat as xs:integer*)[position() lt 4] and: (typeswitch ( local:items() ) case $new as xs:integer* return $new default return fn:error())[position() lt 4]
The dynamic semantics in the FS generally follows an 'eager' or 'strict' evaluation strategy. (E.g., for a function call, it evaluates all arguments before invoking the function.) The normalization rule for 'treat as' is just another example of that.
OK - thanks. This (I think) is the only normalization rule that an implementation might want to avoid!