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 following tests all fail static type checking as they contain expressions which expect something with type quantified ZeroOrOne, but are passed in a child:: expression which can return more than elements. For example, from externalcontextitem-5 for $var in $input-context1/works/employee[1] return $var/xs:float(hours) The other tests are similar. Could they be changed to exactly-one(hours). Relavent tests are: externalcontextitem-2 externalcontextitem-3 externalcontextitem-4 externalcontextitem-5 externalcontextitem-6 externalcontextitem-7 externalcontextitem-8 externalcontextitem-10 externalcontextitem-11 externalcontextitem-12 externalcontextitem-13 externalcontextitem-14 externalcontextitem-15 externalcontextitem-16 externalcontextitem-17 externalcontextitem-18 externalcontextitem-21
It occurs to me that my making all these changes to accommodate static typing, the test suite is becoming less effective at testing dynamic typing. A dynamic typing implementation will typically work out for itself that it needs to add an exactly-one() test to the expression tree, and if it's already been added "by hand" then there's a path in my product that is no longer being tested. So I don't think it's a good idea to change all the tests as is being requested. I'd like some of them to stay as is, and to be marked in the catalog as failing under static typing.
Note: The testing suite is not meant to check implementation code paths but functionality interop. But I agree that it may be useful to duplicate such tests with and without the exactly-one().
The task force has discussed this and I've myself mentioned the problem that testing dynamic implementations becomes less effective with the fixes usually applied for incorrectly typed tests(lame pun intended). Currently two approaches have been suggested: either an alternate query or additional baselines on a per-test basis for static typing implementations.
nametest-8 nametest-10 nametest-11 have similar problems
As have copynamespace-3.xq copynamespace-4.xq copynamespace-5.xq copynamespace-6.xq copynamespace-7.xq copynamespace-8.xq copynamespace-9.xq copynamespace-10.xq copynamespace-11.xq copynamespace-12.xq copynamespace-13.xq copynamespace-14.xq copynamespace-15.xq copynamespace-16.xq copynamespace-17.xq copynamespace-18.xq copynamespace-19.xq copynamespace-20.xq copynamespace-21.xq copynamespace-22.xq
*** Bug 3944 has been marked as a duplicate of this bug. ***
A fix has been attempted in CVS, XQTS_current.zip is updated. If the resolution is satisfactory, feel free to change status to CLOSED. Otherwise, reopen this report. If no feedback is returned within two weeks, status will be changed to CLOSED. Thanks for reporting!
Thanks. I think they are all work with static typing, except nametest-8 which has a parsing error (extra right parenthesis on the last line)
All the externalcontextitem and nametest tests now appear to static type correctly, but am still getting problems for the copynamespace queries where things like: in-scope-prefixes($new//child::*) fail to type check as $new//child::* type as quantifier *, but in-scope-prefixes expectes a single element.