Please look at XPath errata document issued by W3C

[David_Marston@lotus.com]

If you visit
http://www.w3.org/1999/11/REC-xpath-19991116-errata/
you'll see several significant clarifications to XPath. Reading
this should help you think about the testing implications.

I see test labs primarily taking two approaches:
1. Apply an OASIS test suite that includes all the tests marked
   for the latest errata, and report discrepancies against that
   standard. The lab would take the attitude that every processor
   should conform to the spec-with-errata, sooner or later.
2. Apply an OASIS test suite that has been filtered back to just
   the base 1.0 spec, then regenerate the suite with errata
   awareness (matching case 1 above), and report discrepancies
   related to the errata as to-do items for the processor
   developer, supplementing their report on conformance at the
   baseline level.

What I see as much less likely is for the test lab to merely
test against the 1.0 base and say nothing about the test results
with errata awareness. We already know what's in the errata (for
XPath, anyway) so any non-conformance at that level ought to be
useful information.

Does anyone care about testing those cases that are disallowed
by the errata but permitted at the base level only due to its
vagueness? Here's an example: floor(-0) is specified by the
errata to be -0. A test that verifies that behavior of floor()
would be marked as a test for "XPath 1.0 + Errata 1" using some
as-yet-unspecified syntax. Does anyone want to see a test case
for floor(-0) returning +0, but marked as "XPath 1.0 base only"
and obsolete for higher versions? The alternative is to make no
test at all for floor(-0) in the 1.0 base test suite. At the
baseline level, floor(-0) could return either -0 or +0 and be
conformant.
.................David Marston