This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Literals036-055, and Literals068 and Literals069 have their 'is-XPath2' attribute set wrong. The last two specify true while they should be false, and 036-055 should have is-XPath2 true, from what I can tell. This is after a quick look, and it wouldn't surprise me if there's many test cases with this problem. I don't think it would be wise to manually review the test cases because it's time consuming, error prone, and a single review doesn't take into account new test cases in the future. I suggest that you with a harness for a stable implementation(Saxon, if no one else) attempt to run the XPath-only test cases as XPath expressions(not XQuery) and review what test cases that fails. I'm unfortunately not in the position to be able to do this. Cheers, Frans
This bug deals with the 'is-XPath2' attribute that can optionally be applied to test cases to designate their effectiveness in testing XPath 2.0 functionality. I beleive that Joanne was responsible for this?
Thanks for pointing this out. I previously used the XPath parser to determine the value of is-XPath2. I haven't done this for quite some time so for many of these tests, is-XPath2 attributes were set manually. I will run my scripts again. thanks, Joanne
Nice. I have a followup question: Some implementations are XPath-only engines and it is thus of interest to write tests which ensures constructs specific to XQuery are considered syntax errors. From what I understand such a scenario is outside the scope of XQTS; but is it correct to write tests which have is-XPath2=true, contains XQuery constructs, and test whether the engine flag it as a parser error? That is, does "is-XPath2=true" have the more informative meaning "This test case contains XPath-only constructs", or does it mean "This test is for XPath-only engines, thus, XQuery constructs naturally are syntax errors"? If I later on submit tests which have is-XPath2=true, contains XQuery constructs and should fail with a parser error(despite them being valid XQuery constructs), would they be valid tests? Cheers, Frans
They are not valid tests in this suite. The original reason for adding this attribute to the catalog was to get a rough idea on XPath 2.0 coverage in the XQuery suite. This attribute is set to true if the query can be easily converted to an XPath expression within an XSLT stylesheet. This attribute was not designed to be interpretted by a test harness. Thus, XQuery implementors do not have to filter certain tests based on the value of this attribute.
Just ran the script. thanks, Joanne