[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: HOW IT WORKS 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 XSLT.) 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