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

i'd given up on this, but as you were kind enough to try again to make 
your stand point clear to me, i'm quite willing to, once again, reply.

in short, "expanded name" is fine, but the justification for qname 
casting simply makes no sense.

On Tuesday, Nov 4, 2003, at 19:33 Europe/Berlin, Jonathan Robie wrote:

> At 06:55 AM 10/27/2003, Kay, Michael wrote:
>
>> ..
>>
>> 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.
>
> The term 'lexical QName' makes sense here, because it means quite 
> literally something which matches the production for a QName:
>
> [6]     QName    ::=    (Prefix ':')? LocalPart
>
> When we find one of these names in a query, we can expand the name 
> using the URI that is bound to the prefix. The result of this is an 
> 'expanded name'.
>
> These terms seem sensible to me.

yes! yes! [6] has never been an issue, and please, as soon as one is 
prepared to leave the term "QName" out of the description of (iri X 
local-part) combinations i will shut up and sit in the corner.

>
>> > 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.
>
> Actually, this is not true. We decided to remove the inverse 
> operation, that casts an arbitrary QName to a string, and I think it 
> likely that we will need to add this functionality back because we 
> need it to define some of our internal operations.
>
> 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 )
>
> Hope this helps,

thank you, but no, it does not.

it neither deomstrates why one should need to do this nor why one 
should be allowed to. i keep asking for a demonstration because neither 
an implementation of xslt, nor an implementation of xquery required its 
implementation except specifically in order to satisfy the respective 
spec's stipulation that the function be defined. no robust application 
could seriously include the expression

     make-empty-element( xs:QName("james") )

the whole point of this typing business is to make things robuster 
isn't it? why, then, specify your language to include operations which 
do not necessarily close over the data domains. the only thing which 
makes sense is something of the order of

     make-empty-element( xs:UName("", "james") )

anything else is the logical equivalent of doing floating point 
arithmetic on pointers to known integer data.

...

Received on Thursday, 6 November 2003 11:22:28 UTC