Call for Nominations - Deliverables

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

What is needed:

    Deliverables:
    [description of deliverables goes here]

This is something I've been thinking a lot about and I need you to bear 
with me for what may appear at first glance an extravagant plan, but I 
think it is both workable and most flexible for our target.

First, what is our target audience for this report?

(i) - vendors of processors wanting to test their programs
(ii) - customers of processors wanting to test the claims of vendors
(iii) - members of the community interested in the parameters of 
conformance, but not in any test files
(iv) - others?

One thing to note about our target audience is that one size does not fit 
all.  I feel our report needs to be able to be projected in different ways 
for different members of our audience.

Here, then, are my initial ideas of what our deliverables could be:

(1) - entire report content in XML (normative)
(2) - package of entire suite of associated test files, result files, and 
catalogue in XML (normative)
(3) - report configuration document model in XML (normative)
(4) - sample human-legible rendition(s) of report in HTML (non-normative)
(5) - sample machine-legible rendition(s) of report in XML (non-normative)

The "report" (item 1) would be all of the prose, indexes, descriptions, 
summaries, etc. that describes *all* of the "associated test files" (item 2).

I anticipate there will be a number of different renditions of the report 
that will be useful to different users of the report, triggered by a 
configuration (item 3).  These renditions would include (but not be limited 
to):

   (a) - management summary only
   (b) - summary of all tests in all configurations
   (c) - tests only for XSLT processors without error reporting
   (d) - tests only for XSLT processors with error reporting
   (e) - tests for XSLT processors that report all errors except template 
conflict rules
   (f) - etc., etc., etc.

These renditions would be in HTML (item 4; for human consumption) and in 
XML (item 5; for machine automated consumption, as in automated test 
harnesses).  
Since renditions are subject to the environment in which they are run, I 
would posit the renditions are *not* normative, but only informative, and 
that the only normative components are those components from which the 
renditions are created.  Something along the lines of the warning at the 
gas pump: "in cases of discrepancy at the cash (the rendition), the value 
at the pump shall be considered correct (the normative)".

This also gives us some protection in case we screw up a rendition:  the 
rendition is only an informative projection of the normative parts that are 
interesting or relevant to the rendition.

I can picture the configuration file (in XML; what else?) turns on and off 
various switches indicating the nature of the tests desired based on the 
kind of processor being tested and all of the flexible interpretation 
points identified in the Recommendation.  The combination of the 
configuration file and the normative packages would (using XSLT; what 
else?) produce the renditions that are of interest to different
members of our audience.

A user of our report wanting to use a test harness of some kind, would 
configure their needs in the configuration file, project both an HTML 
documentation file and an XML automation file, feed the XML automation file 
to the test harness with a given processor to ascertain the results of that 
processor against only the files in the projection, and then interpret the 
results based on the HTML documentation and the harness' ability to compare 
the actual results with expected results.

My concerns addressed by this approach are based on so very many aspects of 
flexibility given to the creator of an XSLT processor by statements in the 
Recommendation.  Different vendors will make different choices, different 
customers will have different needs.  This approach covers all the bases by 
our normative content and everyone uses only that which is needed for what 
it is they want tested, without being distracted by that which does not 
apply to their particular situation.

................. Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/m/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-04-7
Next instructor-led training:    2000-05-02,2000-05-11/12,2000-05-15,
-                                    2000-06-12,2000-06-13,2001-01-27