On Wed, Aug 16, 2006 at 05:13:06PM +0200, Jens Teubner wrote:

On Wed, Aug 16, 2006 at 10:30:34AM +0200, Stefan Manegold wrote:

...

Hi Pathfinders,

W3C's XML Query Test Suite (XQTS) makes excessive use of type casts a la

xs:TYPE(X)

Pathfinder, however, doesn't like this, complaining about

reference to undefined function `xs:TYPE'

[...]

Instead, Pathfinder seem to prefer type casts a la

X cast as xs:TYPE

What's the desired solution to solve this problem? Implement also "xs:TYPE(X)" in Pathfinder? Or "customize" all XQTS tests to use "X cast as xs:TYPE" instead of "xs:TYPE(X)"?

In XQuery speak, the operators of the form

xs:TYPE( ... )

are referred to as ``constructor functions'' (not casts). They do have the same semantics as the respective `cast as' clauses.

In my opinion, the "desired solution" is to implement the xs:TYPE() constructors in Pathfinder and not patch the XQTS tests again. We can hardly claim to be compliant if we need to patch the majority of the tests in advance.

I am not an expert in milprint_summer. Any volunteers?

Jens

Agree (though I just patched my XQTS harness to patch the queries on-the-fly --- results come in some hours...).

I'm not an milprint_summer expert either --- surely not for built-in functions, but I guess there are no "templates", i.e., the constructor functions need to be implemented for each (supported) type explicitly, right?

Well, a hack(?) I could think of would be to have these constructor functions mapped to the respective `cast as' clause "somewhere" earlier in the parser/compiler in a generic way, i.e., any `xs:TYPE( ... )' is treated as `... cast as xs:TYPE'; then the rest should work "automatically, right? --- I have no idea, though, whether this is (1) correct, (2) possible, (3) indeed less work than the explicit implementation of "all" constructor functions...

Comments?

Stefan