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