Re: Refinements on flow diagram for committee deliverables

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

At 00/06/06 19:33 -0400, G. Ken Holman wrote:
>Based on our discussions yesterday, I've added the bits to the diagram 
>that I had only assumed yesterday but realized at the meeting it was 
>necessary to draw everything out:
>
>   http://www.oasis-open.org/committees/xslt/contributions/Holman-20000606.gif
>....
>I will work on the minutes for yesterday's on my flight to Paris (I leave 
>in 25min).  I will include a narrative to accompany this diagram.

I couldn't find a place for the narrative in the minutes, so I'll use this 
message to do capture my thoughts.

The version of the diagram corresponding to this narrative is 2000-06-06 18:20.

There are three major stakeholders, and thick vertical lines delineate the 
files under the purview of each stakeholder:
   (1) - the submitters who have tests,
   (2) - the committee who collects, documents and packages the tests
   (3) - the users who use the tests with processors

The submitters have a collection of test files and is asked by the 
committee to include a catalogue instance that describes the tests.  The 
catalogue file could, possibly, be derived in whole or in part from the 
content of the tests themselves, but that is not material.  The committee 
will publish a document model with which a submitter is obliged to submit 
the test files.

The test files meet the submitter's requirements, and not necessarily those 
of the committee, so the committee will maintain an exclusion instance to 
note those submitted tests not to be included in the normative 
package.  This allows the submitter's files to be handled in a read-only 
fashion.  Only those files wanted by the committee end up in the normative 
package.

An assembly control instance maintained by the committee will bring 
together the exclusion instance, the submitters' catalogue files, and any 
and all documentation files maintained separately (due to different file 
maintainers).  There will be enough cues, triggers and flags such that the 
normative complete conformance package content is assembled without 
operator intervention on a demand basis by the committee.

The normative package contains all of the test files desired by the 
committee and all of the associated documentation.  The XSLT and XPath 
recommendations identify a number of optional features or toggles 
implemented one way or another by a given processor.

A user configures a rendition control instance with the toggles applicable 
to a given processor (hopefully made available by the processor 
developers).  The committee will supply scripts that render a specified 
configuration of the test suite with only the applicable tests and expected 
results.  In this way users are not burdened with determining if a failed 
test does or does not apply to their given processor; if possible all tests 
will be written such that when executed by a processor claiming to support 
the facility, a failure in the test indicates a failure in the processor to 
be conformant.  Such a result will only work if inapplicable tests cannot 
muddy the waters.

A given configuration of the test suite includes the documentation 
component, a human-legible summary of the tests, the test files and their 
expected results, such that a reader of the package can see a summary of 
the associated text for the report.  A process control component, a 
machine-legible summary of the tests such that a set of test files can be 
executed with the correct invocation details, is produced along side of the 
description.  As well, all test files are made available as part of the 
configured package.

This may differ from traditional approaches of using static test suites as 
compiled from others, in that the user builds their needed test suite from 
the master package.

Working scripts and sample rendition control instances will need to be 
packaged for our users.  A number of document models need to be designed 
and implemented using XSLT scripts bring in information consistently and to 
put out information in a timely and expected fashion.

I think that is all I need to say about the diagram ... if you have any 
questions, please do not hesitate to ask!

Thanks!

.............. 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.
Book: Practical Transformation Using XSLT and XPath ISBN1-894049-04-7
Next instructor-led training:    2000-06-12,2000-06-13,2000-09-19/20,
-              2000-10-03,2000-10-04,2000-10-05,2000-11-13,2001-01-27