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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4273





------- 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
content).

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
[err:FOTY0012]."

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
'none'.

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
typing.

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

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

<a>
    <b id="person0">
        <c/>
    </b>
</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.

So

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