W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2008

[Bug 5696] Feature request to aid static typing

From: <bugzilla@farnsworth.w3.org>
Date: Fri, 16 May 2008 15:47:05 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1Jx29B-0000mw-Ph@farnsworth.w3.org>

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

           Summary: Feature request to aid static typing
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XQuery 1.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: nick@cbcl.co.uk
         QAContact: public-qt-comments@w3.org


We've been looking at static typing in the new functx tests, and have come
across some queries which we are unable to rewrite so they type check, for
example:

declare function functx:value-except
  ( $arg1 as xs:anyAtomicType* ,
    $arg2 as xs:anyAtomicType* )  as xs:anyAtomicType* {

  distinct-values($arg1[not(.=$arg2)])
 } ;

because fs:equal is not defined for all pairs of atomic types in
xs:anyAtomicType an XPTY0004 is thrown.

Obviously, separate value-except-type functions could be defined for arguments
of each atomic type. But we can't think of any other way to rewrite such a
function to type check. We propose two options to "fix" this problem.

Option 1
--------

Recall the general comparisons expand (roughly) out to to the form:

some $x in $arg1 satisfies
  some $y in $arg2 satisfies
    $x op $y

So currently the queries

(1, "foo") = "foo"

and

("foo", 1) = "foo"

may return true or XPTY0004, depending on the order in which
the implementation happens to process the query.

We'd like to propose that if the value comparison used in the 
expansion of the general comparison is not defined for the input
types, then the result is false.

Thus

(1, "foo") = "bar"

would return false.


Option 2
--------

Add generics.

declare function functx:value-except
  ( $arg1 as type(T) <: xs:anyAtomicType* ,
    $arg2 as T )  as T {
  distinct-values($arg1[not(.=$arg2)])
 } ;

This of course would open up a need for a whole host of 
type-describing syntax, e.g. to specify subtype releationships,
type unions etc.

Option 3
--------

We could fix this query by using XQuery 1.1 try/catch.

".=$arg2" would have to be expanded out manually to "some" expressions
with a try/catch to return "false" when the XPST0004 is raised.

This would be rather clumsy.

Option 4
--------

Define union, except, intersect functions/operators which work nicely
with xs:anyAtomicType* input.  Obviously this doesn't fix the general case.

Our guess is that option 1 will make a wider variety of queries run in 
static typing mode, but introducing a breaking change with XQuery 1.0
might be unacceptable.

Option 2 might be nice but might require a fair amount of work by the 
Working Group.
Received on Friday, 16 May 2008 15:47:41 UTC

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