W3C home > Mailing lists > Public > www-ql@w3.org > April to June 2003

RE: typed-value accessor

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Mon, 9 Jun 2003 16:41:35 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DCEE1@daemsg02.software-ag.de>
To: Andrey Fomichev <fomichev_andrei@mail.ru>, www-ql@w3.org

Correct, text nodes have no type annotation.

The only time you ever need to use text nodes is when handling mixed
content, in which case you can't assign a type to the text nodes in your
schema. There is no need ever to retrieve the text node of an element with
simple content, so I don't see it as a problem that it is untyped.

Michael Kay

> -----Original Message-----
> From: Andrey Fomichev [mailto:fomichev_andrei@mail.ru] 
> Sent: 09 June 2003 14:46
> To: www-ql@w3.org
> Subject: typed-value accessor
> Hello!
> I've been working on XQuery implementation for more than a 
> year and I've been seeing some weaknesses in XQuery 
> specification. But now when the Last call of Data Model is 
> released, I'm worried about some things very much. Sorry, if I wrong.
> Suppose we have variable $x bound to XML element <a>5</a> 
> with integer type annotated. And we have the following two 
> expressions: 1. $x + $x 2. $x/text() + $x/text()
> According to data model and XQuery specification the first 
> expression evaluates to atomic value, which has value 10 and 
> type integer. The second expression evaluates to atomic 
> value, which has value 10.0 and type double. The results are 
> different.
> The key to the problem is the following phrase from 
> definition of typed-value accessor from Data Model.
> If the node is a comment, document, namespace, 
> processing-instruction, or text node, then its typed value is 
> equal to its string value as an instance of xdt:untypedAtomic.
> So, does it true, that text nodes have no type annotation? If 
> it is true, it can lead to some strange behavior of query 
> processors, as it is shown.
> Hope, that I wrong,
> Andrey Fomichev
Received on Monday, 9 June 2003 10:41:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:42 UTC