Re: [DM] Typed value for elements

Michael Kay wrote:

>>It would be much simpler and cleaner to say that 
>>dm:typed-value() returns an error for any node with child 
>>elements. This is incompatible with the behavior of XPath 
>>1.0, but so is the current behavior for elements of known 
>>complex type.
>>
>>    
>>
>
>This would mean that given:
>
>  <div>
>    <head>The properties of H<sub>2</sub>O</head>
>  </div>
>
>The expression:
>
>  <xsl:value-of select="div/head"/>
>
>would break.
>  
>
This is the kind of example I have seen most frequently in this 
discussion - examples where formatting occurs in a string, and either 
string comparisons or value-of are done.

It's not clear to me that value-of, which exists for the purpose of 
creating a text node, should drive the semantics of dm:typed-value(), 
which exists for the purpose of deriving typed values. You could, for 
instance, say that value-of implicitly uses string() as part of its 
definition:

    <xsl:value-of select="string(div/head)"/>

This seems preferable to moving the string value into the definition of 
typed value, and works regardless of the definition of the element, so 
it gives you better compatibility with XSLT 1.0. In XQuery, I do not 
think that the following should silently return true:

let $h := <head>The properties of H<sub>2</sub>O</head>
return $h = "The properties of H2O"

I do think that the following should return true:

let $h := <head>The properties of H2O</head>
return $h = "The properties of H2O"

And I think that the two cases should be distinguished.

>What's more, it would work on the first 200 documents that you test it
>against, if your testing is sufficiently thorough, and it would then
>break on the 201st.
>
>Not acceptable!
>  
>
But I don't see how the current definition fixes this problem. Consider 
the following expression:

    for $i in document('201.xml')//foo
    return <twice>{ $i * 2 }</twice>

With either definition, you either get a result or an error depending on 
the values of individual 'foo' elements. For instance you would get an 
error if the value of "foo" is:

    <foo>Hi, Mom!</foo>

You would also get an error if the value of "foo" is:

    <foo><asdf>123</asdf></foo>

Do you really believe that it is not acceptable for the behavior of an 
operation to depend on the value of an operand? Of course, if you have a 
schema that defines the 'foo' element, you can know what it can contain, 
but arbitrary operations on unknown elements can raise errors. Defining 
value-of in terms of string value may well be desirable for XSLT. But I 
don't think that's the right definition for the typed value in XPath.

>Breaking in the case of element-only content (as currently defined) is
>much more acceptable because (a) it only breaks if you add a schema, (b)
>this kind of construct with element-only content is unusual, whereas
>with mixed content it is very common, and (c) it would break on the
>first document you tested it against.
>  
>
But I still don't think it's what you want for value-of in XSLT, is it? 
I think value-of should try to be compatible with XSLT 1.0, for this 
case as well as the others. But value-of and typed-value have different 
design criteria.

Jonathan

Received on Thursday, 12 February 2004 13:55:29 UTC