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 HOF feature is optional, so the tests in FOTS using the HOF feature should have a <dependency type="feature" value="higher-order-functions" satisfied="true"/> node added. If I am not missing something, all test cases that satisfy the condition: matches(fn:data($test-case/fots:test),"(function\-lookup)|(function\-name)|(function\-arity)|(map)|(filter)|(fold\-left)|(fold\-right)|(map\-pairs)|(#[1-9])")) should be marked with a HOF dependency.
I have marked a great many tests with the dependency higherOrderFunctions; see for example http://dev.w3.org/cvsweb/2011/QT3-test-suite/fn/function-lookup.xml?rev=1.20;content-type=text%2Fplain where it is defined at test-set level. If you find specific tests that are missing this dependency - and there are bound to be some - please let us know.
Created attachment 1246 [details] These tests do not have a HOF dependency defined on neither test case nor test set level If I am not missing something, all the tests with a $test node that returns true for: matches($test,"(function\-lookup)|(function\-name)|(function\-arity)|(map)|(filter)|(fold\-left)|(fold\-right)|(map\-pairs)|((a-z)*#[0-9])")) should be marked with a HOF dependency at the test case level. The mentioned tests are checked for a HOF dependency at both test case and test set level first.
Thanks Sorin for the comprehensive list. I have made the changes and committed them to cvs. No change were made to the test-cases: require-higher-order-function-4-ns require-higher-order-function-9-ns prohibit-higher-order-function-4-ns According to the description of these the desired affect of switching off the HOF features in the implementation is that we expect an error. Just to note that some implementations, like ours, may not be able to switch of features externally! I think Ghislain should look at these test cases again.
Are you sure you pushed the updates to CVS for all reported cases? The following have not yet been updated: <test-set name="fn-data"> <test-case name="K2-DataFunc-5"/> </test-set> <test-set name="fn-map"> <test-case name="map-006"/> </test-set> Also please wait a bit before marking the bug as fixed because I will post another list of test-cases that might need HOF dependency added. The REGEX I used to identify the first list of tests did not catch all concurrences.
(In reply to comment #4) > Are you sure you pushed the updates to CVS for all reported cases? > > The following have not yet been updated: > <test-set name="fn-data"> > <test-case name="K2-DataFunc-5"/> > </test-set> > <test-set name="fn-map"> > <test-case name="map-006"/> > </test-set> > > Also please wait a bit before marking the bug as fixed because I will post > another list of test-cases that might need HOF dependency added. > > The REGEX I used to identify the first list of tests did not catch all > concurrences. OK: here are all the cases that should be looked into: <test set name="fn-map">add HOF dependency for the whole test set</test set> <test set name="prod-NamedFunctionRef">add HOF dependency for the whole test set</test set> <test-set name="fn-data"> <test-case name="K2-DataFunc-5"/> </test-set> <test-set name="fn-map"> <test-case name="map-006"/> </test-set>
Hi O'Neil, You are right - the test cases *-ns correspond to the assumption that a given feature (here, HOF) is not supported, and are hence marked with <dependency type="feature" value="higherOrderFunctions" satisfied="false"/>. If an implementation does not support HOF, it must run these tests to check that it behaves appropriately for require-feature/prohibit-feature. (In reply to comment #3) > Thanks Sorin for the comprehensive list. I have made the changes and > committed them to cvs. > > No change were made to the test-cases: > require-higher-order-function-4-ns > require-higher-order-function-9-ns > prohibit-higher-order-function-4-ns > > According to the description of these the desired affect of switching off > the HOF features in the implementation is that we expect an error. > > Just to note that some implementations, like ours, may not be able to switch > of features externally! I think Ghislain should look at these test cases > again.
I added HOF dependency tags to the following test sets: fn-map prod-namedFunctionRef as well as to the following test cases: fn-unparsed-text-003 fn-unparsed-text-004 fn-unparsed-text-available-003 fn-unparsed-text-available-004 fn-unparsed-text-lines-003 fn-unparsed-text-lines-004 K2-DataFunc-5
> Just to note that some implementations, like ours, may not be able to switch > of features externally! I think Ghislain should look at these test cases > again. My understanding is that it is not required to switch off HOF. If an implementation supports HOF and does not provide a means of switching it off externally, I think the semantics of the tags set to false is that it should just skip (ignore) these tests.
I have also added a dependency tag on test case contextDecl-055.