W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2007

[Bug 4273] [FS] data on element()

From: <bugzilla@wiggum.w3.org>
Date: Tue, 23 Oct 2007 09:01:22 +0000
To: public-qt-comments@w3.org
Message-Id: <E1IkFda-0002kv-RA@wiggum.w3.org>


------- Comment #17 from tim@cbcl.co.uk  2007-10-23 09:01 -------
As Bill Patton has pointed out in a message to public-qt-comments, data on is
not always defined.  Quoting FS:

"The data on filter is not defined on any element type whose type annotationXQ
denotes a complex type of complex content and therefore applying data on to
such a node raises a static error."

He therefore concludes that fn:data applied to a value whose static type is
known to be element() must necessarily raise a static type checking exception
(because it is conceivable that the element supplied at runtime is has complex

If however, this was replaced with:

"If ElementType denotes a complex type of complex content then the static type
is 'none' and applying fn:data to such a node raises a dynamic error

Thus 'data on' is always defined.  That's nice, because the type declaration of
fn:data is:

fn:data($arg as item()*) as xs:anyAtomicType*

i.e. it would be surprising to an end user if fn:data couldn't pass static type
checking for any item().  

The cases where 'data on' is 'none' is exactly the cases where fn:data is
defined to raise the error [err:FOTY0012], and of course, fn:error has type

While I realise that avoiding these sort of runtime errors is static type
checking's raison d'etre, however we risk making a static typing implementation
completely unusable.

XQTS test K2-Axes-81 is an example of a query which is painless with optimistic

    <b id="person0">
</a>/*[attribute::id eq "person0"]/c

To make this pass static typing, it has to be modified to:

    <b id="person0">
</a>/*[(data(attribute::id) treat as xs:untypedAtomic) eq "person0"]/c

Not pretty, but it works.  The static type of data(attribute::id) is
xs:anyAtomicType*.  However, the computed value of the attribute will be
xs:untypedAtomic, meaning that 'treat as' will not raise a runtime type error.


data on element(*, xs:anyAtomicType*) = xs:anyAtomicType*

but when fn:data is applied to an element whose schema type no more specific
than anyType, fn:data will return an untypedAtomic value.
Received on Tuesday, 23 October 2007 09:01:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:20 UTC