RE: WD-xpath-functions-20030502: casting xs:QName

> Here's a use case for casting to xs:QName. Suppose I write a 
> function that 
> creates an element with a given name:
> 
> declare function make-empty-element($n as xs:QName)
>      as element()
> {
>      element { $n } { }
> }
> 
> Now I want to be able to call this function. Sensibly, my 
> function requires 
> a QName for the element name, so it can only be called with 
> this type of 
> parameter. Now I want to call this function to create an 
> element named 
> "james". To do this, I need to cast a string to a QName:
> 
>     let $n := xs:QName("james")
>     return make-empty-element( $n )
> 

This is certainly a good use case. However, it's interesting that the
argument to the xs:QName constructor is a string literal. But actually any
expression that yields a string can be used here. I don't think there's a
convincing use case for constructing a QName dynamically, using the
namespace bindings that are declared statically. If you did want to
construct a QName dynamically, I think you would want to construct it from
the namespace URI and local-name, using the fn:expanded-QName() function.

The case that causes the pain is the function that makes run-time use of
namespace prefixes declared in the query, because it means that implementors
have to keep the static namespace context around at run-time. I don't think
we would lose anything if we restricted this constructor to take a
string-literal, or alternatively if we provided syntax such as #james or
#my:name to denote a literal QName value. I'm not generally in favour of
arbitrary restrictions, but it does seem to me that the namespace prefixes
declared statically in the query (like the variable names and the function
names) are something that ought to exist at compile time only. 

(XSLT makes use of dynamically constructed lexical QNames all over the
place, and I think it's a mistake, although it's too late to change it).

Michael Kay