This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3697 - K-FilterExpr-66
Summary: K-FilterExpr-66
Status: CLOSED FIXED
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Frans Englich
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-11 13:56 UTC by Tim Mills
Modified: 2010-03-16 15:52 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2006-09-11 13:56:55 UTC
The query:

0 eq (0, 1, 2)[1 eq position()]

fails static type checking because, without simplification, the right hand side has type integer*.
Comment 1 Tim Mills 2006-09-11 16:37:05 UTC
Similar results are obtained for:

K-FilterExpr-67
K-FilterExpr-68
K-FilterExpr-73
K-FilterExpr-78
K-FilterExpr-79
K-FilterExpr-80
K-FilterExpr-82
K-FilterExpr-90
Comment 2 Frans Englich 2006-09-13 20:21:42 UTC
One problem with fixing tests, such as these, that violate the static typing feature is that it requires adding XPTY0004 as alternative baseline(if one doesn't decide to rewrite the test, which often spoils the intent with the test).

The problem is that XPTY0004 is too wide, an implementation could issue XPTY0004 for a reason that isn't valid and therefore incorrectly pass the test.

The proper thing would be to have a specific error code for static typing errors. I believe defining the semantics for that error code is formally possible and reasonable to implement. It would also make static typing behaviors more easy to identify for users.

Well, it's a pity such things are realized first now.
Comment 3 Tim Mills 2006-09-14 06:44:13 UTC
That certainly sounds reasonable, although it would be nice for an implementation which follows the Formal Semantics document precisely to be able to pass the tests.   

Many of the problems we've encountered would go away with the use of fn:exactly-one , fn:zero-or-one, or application of [1] filters.  Would such changes 'damage' many tests?

So far we've only been testing an XPath 2.0 implementation.  We've used XQTS, ignoring those tests which are XQuery-only.  That's left about 11000 of the minimal-conformance tests of which we fail about 200, mostly due to the type checking problems we've highlighted.

We hope to get a full XQuery implementation ready soon to see how we fair on the remaining tests.
Comment 4 Frans Englich 2006-09-14 11:57:15 UTC
Yes, I think so, adding exactly-one(), [1] etc changes how it's type checked, and these tests primarily tests that(that's why they get in trouble with static typing).


Frans
Comment 5 Frans Englich 2006-09-15 18:14:54 UTC
I changed the tests to let the baseline do the comparison instead of a call to the 'eq' operator. However, there is the risk that additional type errors hide in the operand, although I doubt it.

Feel free to verify this change. This is fixed in CVS, in XQTS_current.zip. For instruction to download this, see http://www.w3.org/XML/Query/test-suite/, section "Accessing our Source Files". XQTS_current.zip resides in directory PublicPagesStagingArea/.

If the resolution is not satisfactory, re-open this report. Otherwise, if the resolution is acceptable, feel free to change status to CLOSED. Thanks for reporting!


Frans