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.]


with reference to:

17.14 casting to xs:Qname

what is the use case for casting from a string to a universal name.

the ostensible use case from the xpath requirements, section 4.1, is 
nothing more than the circular stipulation, that one must be able to 
both "build a namespace element from a qname" and "compare a namespace 
uri from a qname with a string". that one must permit these operations 
with universal name arguments is self-evident. that one must permit 
these operations with qualified name arguments remains unmotivated.

17.15 casting to xs:NOTATION

contains the sensible proscription, that "it is not possible to cast 
values of any other type to xs:notation, because the validity of an 
xs:notation value is context dependent and cannot, in general, be 
determined."

the same applies to qualified names. if this prescription applies to 
notations, why does it not apply to qualified names?


discussion:

despite the "in-scope namespaces" mechanism which has been suggested as 
a means to model the context-dependency for qualified names, in 
general, the solution requires that the lexical contours correspond the 
the granularity of a name. unless that is done, in general, combination 
operations do not close over the model. the increasingly complex rules 
for "namespace fixups" and "in-scope namespace inference" 
notwithstanding.

as a consequence, an implementation cannot simultaneously support those 
aspects of the (qualified-name -> universal-name) operations which 
stipulate a dynamic context and fulfill query requirement 3.4.5.

until those aspects of the operations on qualified names which specify 
support for dynamic contexts are motivated by specific use cases, and 
then only if those use cases cannot be accommodated by operations which 
are expressed in terms of uri and local parts, the dynamic components 
of name operations should be removed from all standards.

...

Received on Sunday, 26 October 2003 06:22:45 UTC