This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The query: 0 eq (0, 1, 2)[1 eq position()] fails static type checking because, without simplification, the right hand side has type integer*.
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
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.
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.
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
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