W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2004

Re: [FO] Bug in contains()

From: Jonathan Robie <jwrobie@mindspring.com>
Date: Mon, 16 Feb 2004 13:50:48 -0500
Message-ID: <40311108.8000603@mindspring.com>
To: Michael Kay <mhk@mhk.me.uk>
Cc: 'Jonathan Robie' <jonathan.robie@datadirect.com>, 'Michael Rys' <mrys@microsoft.com>, 'XML Query Comments' <public-qt-comments@w3.org>

Michael Kay wrote:

>>Now I want to do the following query:
>>
>>    let $people := doc('people.xml')
>>    return contains($people, "Rys")
>>
>>When the query attempts to cast $people to a string, it will try to 
>>atomize the element using dm:typed-value(), and the following 
>>rule applies:
>>
>>     If the node has a complex type with complex content, raises a
>>     type error, which may be handled by the host language.
>>
>>We should see if there are other functions/operators that 
>>have this same problem.
>>
>>    
>>
>
>All string functions potentially have this problem, there is no reason
>to special-case contains. For example, it applies just as much to
>concat().
>  
>
I think there are two consistent ways to approach this.

One way is to say that elements with child elements do not have a typed 
value, and to use string-value() when you want the string value. 
<xslt:value-of/> and contains() would then be defined in terms of string 
value, which seems more appropriate to their function. Personally, I see 
no problem with concat() raising an error when you try to treat an 
element with complex content as a string.

Another approach is to say that every element has a type value. Your 
proposal is a reasonable way to do that, and I find it less 
objectionable than the status quo.

A third approach is to say that elements with child elements do not have 
a typed value, but any element can be implicitly cast to a string.

I prefer all three of these approaches to the status quo. Of these three 
approaches, I prefer the first and the third.

Jonathan
Received on Monday, 16 February 2004 13:53:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:57 UTC