Re: [DM] Typed value for elements

Michael Rys wrote:

>See below.
>  
>
And my comments are also interspersed.

>>----Original Message-----
>>From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
>>request@w3.org] On Behalf Of Jonathan Robie
>>Sent: Wednesday, February 11, 2004 6:03 PM
>>To: XML Query Comments
>>Subject: [DM] Typed value for elements
>>
>>
>>The rules for dm:typed-value() are confusing and inconsistent for
>>elements and document nodes. Here is an example that illustrates one
>>set of problems: what is the result of the following query?
>>
>>  <Cities>
>>    <City>
>>        <CityId>01</CityId>
>>        <Longitude>100</Longitude>
>>        <Latitude>32</Latitude>
>>    </City>
>>    <City>
>>        <CityId>02</CityId>
>>        <Longitude>54</Longitude>
>>        <Latitude>24</Latitude>
>>    </City>
>>  </Cities> * 2
>>
>>In the current specification, this question can not be answered unless
>>we know the schema information associated with the Cities
>>element.
>>    
>>
>
>[Michael Rys] 
>Note that this example is a pretty meaningless expression. I do not
>think that we should design for such meaningless cases.
>  
>
I think that was my point. We should not require implementations to 
support this - and especially not with such a strange mix of rules. I 
think that users should get a type error instead of nonsense behavior, 
and I do not think that typed-value() should require extraction of 
entire trees. Users who want that can use string().

>>Here is the current set of rules:
>>
>>1. If the element has a known complex type, and it does not allow
>>mixed content, then it raises a type error.
>>
>>2. If this element's type is xdt:untypedAny, the typed value of the
>>element is its string value, as an instance of xdt:untypedAtomic, so
>>this query evaluates to (2 * 0110032025424). This is surprising, and
>>it is not useful for users.
>>    
>>
>
>[Michael Rys] This is not a problem of the rule but a problem of your
>example. This rule makes lots of sense if you add leave numbers, or if
>you apply a string function to an untyped complex element that contains
>document markup.
>  
>
Please illustrate with examples. Most examples I have seen so far 
involve string comparisons, where people would prefer not to use 
string() explicitly to get the string value of the entire subtree. I 
think this is a heavy operation, and it's not unreasonable to require 
explicit syntax for it.

Obviously, you do need to be able to get the string value of a subtree, 
but this should not be done implicitly. Which is the reason given for 
not doing this if the data has a known complex type.

>>3. If this element's type is known, and it allows mixed content, the
>>typed value of the element is its string value, as an instance of
>>xdt:untypedAtomic, so this query evaluates to (2 * 0110032025424).
>>    
>>
>
>[Michael Rys] This is only true if you are doing dynamic typing. And in
>that case again, you have just shown that your query above is a bad
>example.
>  
>
But I would also like reasonable semantics when I am not doing static 
typing, or when I don't have the definition. I don't know what you mean 
by a bad example - it is an example that illustrates problems with what 
we have defined. Systems should raise an error instead of silently 
producing a nonsense answer.

>>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.
>>    
>>
>
>[Michael Rys] This is a bad rule since it disregards the
>document-centric use case where you want to apply string functions to
>complex content.
>  
>
Look at your sentence - "where you want to apply string functions to 
complex content." The best way to do that is to explicitly apply string 
functions to complex content. There is a reason that every node has both 
a typed value and a string value.

Jonathan

Received on Thursday, 12 February 2004 12:40:29 UTC