OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Prototype 3 ready for download

>David, I need a better understanding of your planned use of version-drop,
>errata-drop, and errata-add, described from the point of view of how you
>want that information processed.  Given the new piecemeal maintenance of
>specification versions and documents, do we still need these properties?

In Iron Man, I wrote:
When rendering a specific instance of the test suite, a test case can be
excluded on any one of the following bases:
A discretionary item of a given name is set to a different value.
A gray-area item of a given name is set to a different value.
The spec-citation/Version value on the test case is numerically larger than
what the processor implements. (This could be for any spec named, not just
There is a spec-citation for a spec (e.g., XBase) that the processor claims
not to implement.
The test lab wishes to test against an errata level that is numerically
lower than the errata-add or higher than the errata-drop for a spec. In the
former case, there should be a cross-check against gray-area items.
Thus, it is the "user" (test lab) who renders a test suite by deciding
which spec version and errata level they wish to test, and by specifying
the settings of the discretionary and gray-area items they know.

So the run-time operation requires the application of data about the
processor under test, plus data about which errata level they wish to be
tested. The test lab must set that data as input to the rendering of a
test suite for a particular test run.

Now let's take the easy case: version-drop. We don't know for sure now,
but it's "highly likely" that XSLT 2.0 will do away with result tree
fragments (RTFs). When we know for sure, the catalog data for each test
that depend on RTFs needs to have a <version-drop> of 2.0 set. So this
is an item for future use, once there is more than one version of the
processor to test against. However, we (Carmelo, I guess) can write the
renderer now to implement exclusion on the basis of version-drop. (BTW,
I have seen no indication that the WG will make it feasible to graft
XPath 2.0 onto XSLT 1.0, but we have the ability to filter tests that
way if it should come to pass.) If the test lab wants to render a test
set for XSLT 2.0, those cases where version-drop is set and is less than
or equal to 2.0 will be excluded. Poof! All the RTF tests are out.

The action on errata is similar, but use of dates is likely to be
necessary. If the processor developer says they implemented all errata
up through 20010915, then the rendering uses that date as the cutoff
between errata-add and errata-drop, as detailed above.
.................David Marston

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC