I propose the following changes to address this bug, to be read in the light of my proposed changes for the static context of a function item literal from bug #9139 comment #14:

From XPath 2.1 section 3.12.2 "Cast", remove:

<remove>
If the target type of a cast expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and if the base type of the input is not the same as the base type of the target type, then the input expression must be a string literal [err:XPTY0004].
Note:
The reason for this rule is that construction of an instance of one of these target types from a string requires knowledge about namespace bindings. If the input expression is a non-literal string, it might be derived from an input document whose namespace bindings are different from the statically known namespaces.
</remove>

From XPath 2.1 section 3.12.3 "Castable", remove:

<remove>
Note:

If the target type of a castable expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and the input argument of the expression is of type xs:string but it is not a literal string, the result of the castable expression is false.
</remove>

From XPath 2.1 section 3.12.4 "Constructor Functions", remove:

<remove>
The constructor functions for xs:QName and for types derived from xs:QName and xs:NOTATION require their arguments to be string literals or to have a base type that is the same as the base type of the target type; otherwise a type error [err:XPTY0004] is raised. This rule is consistent with the semantics of cast expressions for these types, as defined in 3.12.2 Cast.
</remove>

From F&O 1.1 section 17.2 "Constructor Functions for xs:QName and xs:NOTATION", remove:

<remove>
Conversion from an xs:string to a value of type xs:QName, a type derived from xs:QName or a type derived from xs:NOTATION is permitted only if the xs:string is written as a string literal. This applies whether the conversion is expressed using a constructor function or using the "cast as" syntax. Such a conversion can be regarded as a pseudo-function, which is always evaluated statically. It is also permitted for these constructors and casts to take a dynamically-supplied argument in the normal manner, but as the casting table (see 18.1 Casting from primitive types to primitive types) indicates, the only arguments that are supported in this case are values of type xs:QName or xs:NOTATION respectively.
</remove>

From F&O 1.1 section 18.1.1 "Casting from xs:string and xs:untypedAtomic", change:

<quote>
Casting is permitted from xs:string and xs:untypedAtomic to any primitive atomic type or any atomic type derived by restriction, except <remove>xs:QName or </remove>xs:NOTATION. Casting to xs:NOTATION is not permitted because it is an abstract type.
</quote>

<remove>
Casting is permitted from xs:string literals to xs:QName and types derived from xs:NOTATION. If the argument to such a cast is computed dynamically, [err:XPTY0004]XP is raised if the value is of any type other than xs:QName or xs:NOTATION (including the case where it is an xs:string). The process is described in more detail in 17.2 Constructor Functions for xs:QName and xs:NOTATION.
</remove>

One other change in F+O 17.2: "A static error is raised [err:FONS0004] if the prefix is not bound in the static context." This needs to become a dynamic error (with perhaps some note about raising it statically if the argument is known statically).

 

The XQuery and XSLT WGs discussed this bug today and agreed to accept the proposal in comment #1 as extended by comment #2.

In the 10 Dec 2010 draft of F+O, this change is imperfectly implemented:

* In the casting table, the cells uA/QN and ua/NOT should be labelled "M" rather than "N", and coloured accordingly

* In 18.1.1, the sentence "Casting is permitted from xs:string literals to xs:QName and types derived from xs:NOTATION. ", while true, is now misleading and should removed.

The changes proposed in comment #4 were accepted.