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 6.1 Static Typing Extensions, the FS specification states the following: "It is not recommended for a static typing extension to change the static typing behavior of expressions that specify a type explicitely (treat as, cast as, typeswitch, function parameters, and type declarations in variable bindings), since the purpose of those expressions is to impose a specific type." This kind of recommendation is not appropriate for a standard specification. In fact, many desirable static typing extensions will violate this recommendation. This is likely to happen if the specified type is a supertype of the static type result. Consider the following example: declare function local:f($x as xs:decimal) as item* {$x}; local:f(3)+4 The static type analysis can infer that the function retun type is xs:decimal, which is more specific than item*. So an implementation may correctly infer xs:decimal as the static type of local:f() such that that the subsequent static type analysis of addition will be OK. Otherwise, this query will unnecessarily yield pessimestic type errors.
You may be correct for most of the given expressions. But note that a treat as has the explicit purpose to set the static type... Michael (personal response)
*** This bug has been marked as a duplicate of 1708 ***