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

> i note that the comments period for this document is long 
> over. i note 
> also, however, that it has not yet been supplanted. should 
> the occasion 
> arise to release another version, it would be appropriate for it to 
> address the following:
> 
> [note please, except for citations, the following discussion uses 
> "universal name" to describe data of the type (namespace-uri X 
> local-part) and "qualified name" to denote data of the type (prefix X 
> local-part). please do try to retain that terminology in your 
> replies - 
> the term "QName" which appears in the document does little to further 
> careful reasoning, as it is meaningless unless qualified.]

The terminology we are trying to use is "lexical QName" for the (prefix,
local-name) pair, and "expanded QName" for the (uri, local-name) pair. I
agree that we need to be very careful about the distinction and this isn't
always true of the current drafts.
> 
> 
> with reference to:
> 
> 17.14 casting to xs:Qname
> 
> what is the use case for casting from a string to a universal name.

We have decided to remove this functionality, it will disappear in the next
draft.
> 
> until those aspects of the operations on qualified names 
> which specify 
> support for dynamic contexts are motivated by specific use cases

There are still a few situations in XQuery where the static namespace
context needs to be retained at run-time. An example is in computed element
constructors where a construct such as the following is permitted:

element { if (b) then "b:name" else "c:name" } {3}

Michael Kay