[xslt-conformance] Prototype 10: complete merging process (revisedvalidation)

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

Hi folks, I have finally completed a working implementation of the middle 
area of the diagram depicted here:

http://www.oasis-open.org/committees/xslt/contributions/Holman-20000706.gif

This required a number of reworkings of DTDs and configuration instances 
and validation scripts, but they are all complete.

*No* changes are needed to the catalogues of test suites as currently 
supplied; I managed all of the changes in the scripts and DTDs.

Please go to the work page and find three ZIP files for Prototype 10 posted 
today (2002-03-05):

149,150 proto10-validate.zip
163,892 proto10-merge.zip
256,966 proto10-result.zip

The "-validate.zip" is a packaging of the files for a submitter, since they 
don't have any needs for the merge stuff.  This subset of the environment 
meets the needs in the diagram above on the left side ... again, only for 
the submitters of a set of tests for inclusion.

The "-merge.zip" is a packaging of all the files for subcommittee member 
use, including the validation stuff, a test exclusion instance, and empty 
documentation instances.  The "assembly control instance" is the same 
document model as the validation submission instance.  The "merge.xsl" 
implements the process to produce the normative complete package.

The "-result.zip" is the result package from running the merge on the 
number tests.

What remains to be done from the middle area of the diagram are two items 
that are the responsibility of Carmelo:

  - the set of documentation instances from which the user's configured 
report is produced (preamble, descriptions, etc.); note that to remain 
generic, even titles and references in the end user reports that are 
specific to XSLT will have to be found in these instances instead of in the 
stylesheet
  - the stylesheet used by the user to configure a test suite from the 
normative package content

I have taken out the line from the "exclusion instance" to the packaging of 
the test files.  You will see that *every* test file is copied to the 
result, and *every* test file's catalogue entry is copied to the result.  I 
am proposing that when a test is to be excluded, an entry is put into the 
exclusion instance, and that entry is *copied* into the entry in the merged 
result catalogue (again not touching the catalogue file supplied by the 
submitter).

I have included the entire discretionary instance and configuration 
instance in the one XML document instance in the "normative complete 
conformance package content".  I felt this is important to ensure someone 
looking at the merged result also has access to all of the configuration 
and discretion issues associated with our decisions on including or 
excluding tests be found in the one instance and not risk being out of sync 
or separated.  That one XML file in the dotted box contains *everything* 
about the tests except the tests themselves.

It is the presence of the "<excluded>" child in the revised test case 
document model that excludes a test case from use by the catalogue.  The 
justification for this is that we now inherently document not only which 
tests were excluded, but why they were excluded, in the normative package 
content.  A test lab going through the catalogue must not consider any 
entries that have an <excluded> child as being a bona-fide part of the 
test.  Perhaps I should collect these under a different element under the 
document element?  I thought not because there was general consensus in 
earlier meetings that the structure of the catalogues be preserved as much 
as possible for processes to be shared.

It also turns out to be easier to implement this way ... no playing with 
the sets of test files either ... they are copied verbatim as received from 
the submitter.

If we as a committee decide that we really do want to prune the collection 
of files (while maintaining the documentation of the exclusion reason with 
the excluded entry in the catalogue), I'm going to need some advice for 
generically copying only a subset of files.  I can do this by synthesizing 
an MSDOS copy batch file from only the catalogue entry information, or we 
can leave it the way it is and include everything in the result.

Please post to the list your questions about what I've done or how it 
works.  I'll also add this to the agenda.

Note that things are still generic!  There are no dependencies on any 
particular regime in the structure and processes I've created here, so the 
merge process can be used by other committees for other test regimes.

I think the two readme.txt and readme2.txt files are complete ... please 
look for anything missing.  This is not meant to supplant regime 
documentation for making these scripts useful to other standards 
committees.  Keep an eye out for any missing OASIS copyright statements, 
too ... I think I found them all.

If you have time (and a Windows environment) to test what I have completed, 
please give it a try so that you can report any unintended environmental 
dependencies I've created without knowing.

Thanks!

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

--
Upcoming: 3-days XSLT/XPath and/or 2-days XSLFO: June 17-21, 2002
-       : 3-days XML Information Modeling: July 31-August 2, 2002

G. Ken Holman                mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
ISBN 0-13-065196-6                        Definitive XSLT & XPath
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-07-1               Practical Formatting Using XSLFO
XSL/XML/DSSSL/SGML/OmniMark services, books(electronic, printed),
articles, training(instructor-live,Internet-live,web/CD,licensed)
Next public training:   2002-03-01,04,05,06,11,15,04-08,09,10,11,
-              05-06,07,09,10,20,06-04,07,10,11,13,14,17,20,07-31