Static Typing in XQ Update Test Suite
Xavier Franc <[email protected]> Mon, 18 Jan 2010 23:14:58 +0100
| Newsgroups | gmane.comp.web.query-languages |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------050201040102090907090301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Andrew Eisenberg wrote:
> We are still looking for implementations that support the
> Update Facility Static Typing Feature and implementations that support
> XQueryX. We'd like to encourage implementors of these features to submit
> their results to us, so that we can advance XQuery Update Facility to W3C
> Recommendation.
Dear Andrew,
contemplating the test group "Update Facility Static Typing Feature",
I think there are some reasons why no implementations so far can
pass the related tests:
IMHO, there are no more than 10 tests in 27 that really belong to this
category and are correct.
As far as I understand the static typing feature, an implementation
supporting it is supposed to raise an error when the static analysis can
determine that an expression will *certainly* raise an error at runtime:
[XQ 5.2.3 Static Typing Feature]
/If an implementation does not support the Static Typing Feature, but
can nevertheless determine during the static analysis phase that an
expression, if evaluated, will *necessarily raise a type error* at run
time, the implementation MAY raise that error during the static analysis
phase./
It is also stated [XQ 2.2.3.1 Static Analysis Phase]:
/[Definition: The static analysis phase depends on the expression
itself and on the static context. The static analysis phase *does not
depend on input data* (other than schemas).] /
* tests of the kind "ST is too vague" are wrong IMO:
a static type node()* can perfectly correspond to correct node types
at runtime.
* tests of the kind "ST of Target/Source has cardinality greater than one"
- either involve the knowledge of input data (through $input-context),
- or assume that the path-expression will always return several nodes,
which cannot be asserted during static analysis (and BTW it returns
exactly one node).
* Test "stf-insert-02: insert: ST of SourceExpr has non-attribute before
attribute.":
although this error can indeed be detected by static analysis, that
seems
far too complex, and looks more like "formal proof of program" than
like what a compiler can achieve.
Best regards
--------------050201040102090907090301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<span id="from">Andrew Eisenberg wrote:</span><br>
<blockquote type="cite">
<pre id="body">We are still looking for implementations that support the
Update Facility Static Typing Feature and implementations that support
XQueryX. We'd like to encourage implementors of these features to submit
their results to us, so that we can advance XQuery Update Facility to W3C
Recommendation.</pre>
</blockquote>
<br>
Dear Andrew,<br>
<br>
contemplating the test group "Update Facility Static Typing Feature",<br>
I think there are some reasons why no implementations so far can<br>
pass the related tests:<br>
IMHO, there are no more than 10 tests in 27 that really belong to this
category and are correct.<br>
<br>
As far as I understand the static typing feature, an implementation
supporting it is supposed to raise an error when the static analysis
can determine that an expression will <b>certainly</b> raise an error
at runtime:<br>
[XQ 5.2.3 Static Typing Feature]<br>
<i>If an implementation does not support the Static Typing Feature,
but can nevertheless determine during the static analysis phase that an
expression, if evaluated, will <b>necessarily raise a type error</b>
at run time, the implementation MAY raise that error during the static
analysis phase.</i><br>
It is also stated [XQ 2.2.3.1 Static Analysis Phase]:<br>
<i>[Definition: The static analysis phase depends on the expression
itself and on the static context. The static analysis phase <b>does
not depend on input data</b> (other than schemas).] </i><br>
<br>
* tests of the kind "ST is too vague" are wrong IMO:<br>
a static type node()* can perfectly correspond to correct node
types at runtime.<br>
* tests of the kind "ST of Target/Source has cardinality greater than
one"<br>
- either involve the knowledge of input data (through
$input-context),<br>
- or assume that the path-expression will always return several
nodes, <br>
which cannot be asserted during static analysis (and BTW it
returns exactly one node).<br>
* Test "stf-insert-02: insert: ST of SourceExpr has non-attribute
before attribute.":<br>
although this error can indeed be detected by static analysis, that
seems <br>
far too complex, and looks more like "formal proof of program"
than <br>
like what a compiler can achieve.<br>
<br>
Best regards<br>
<br>
</body>
</html>
--------------050201040102090907090301--