More about: Running tests (was: infoset based comparison)

[David_Marston@lotus.com]

>//takes control instance xml with discretionary choices, errat
>level, etc. indicated and returns key for cached test config

This looks more like the "rendering" section of the infamous diagram, as
opposed to running the tests. Quoting Iron Man: 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. Before running the specific
rendition, they must ascertain how they will handle those tests that run
in special scenarios, taking into account the operating system where the
tests will run and processor-specific input and output design.

>Revising, I think only 2 outputs could be: transform and console (which
>is stdout and stderr united).

We should design this so that multiple output files are possible.
XSLT 2.0 will most likely have an xsl:document facility for multiple
outputs, plus we want to make the design adaptable for FOs and other
types of processors. For the short term, we can probably get by with
(A) a single transformation output (one of: XML, HTML, text)
(B) console output (stdout and stderr merged)
(C) both A and B for "warning" messages (e.g., xsl:message)

>//I assume input is always xml

As far as I know, yes.
.................David Marston