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

[XQuery] MS-XQ-LC1-148

From: Michael Rys <mrys@microsoft.com>
Date: Wed, 18 Feb 2004 12:54:29 -0800
Message-ID: <EB0A327048144442AFB15FCE18DC96C70214D25A@RED-MSG-31.redmond.corp.microsoft.com>
To: <public-qt-comments@w3.org>

Section Matching an ElementTest and an Element Node	

The current semantics of element(Name, *) is that it matches any element
of any type (the same as element(Name, xs:anyType). We think that this
semantics is problematic when implementing a statically typed system for
the use case where you want to only operate on untyped data. It seems
counter-intuitive that if I do not care about types, that I actually
have to write the function signature element(Name, xdt:untyped) to
preserve the static untypedness inside a function. It would seem better,
if we can define element(Name, *) to either refer to the untyped case or
make it something that will provide late static type binding by
preserving the inferred type of the expression passed. Note that the
later obviously complicates separate compilation of the function since
you need to know the static type of what is being passed...

Here is an example:

define function addWATax($e as element(invoice,*)) as xs:double
{ $e/cost[1] * 1.088 }

With the current semantics of element(invoice, *), $e/cost[1] would
infer the static type element(cost, xs:anyType)? which currently cannot
be atomized because it may have an non-atomizable element at runtime and
would raise a static type error. By changing the semantics to mean
element(invoice, xdt:untyped) the inference for  $e/cost[1] would be
element(cost, xdt:untyped)? that can be atomized to xdt:untypedAtomic?
which in turn will be promoted to xs:double and the function results in
the expected result.

Note that this issue is preserved even if we change the meaning of
element(name) to mean element(name,*) (see
http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jan/0068.html and
Received on Wednesday, 18 February 2004 15:54:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:55 UTC