Re: Requirements

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

At 01/07/13 17:18 -0400, Carmelo Montanez <carmelo@nist.gov> wrote:
>     Following please find a list of requirements that a user may need
>when examining or executing the tests.

Thanks for pulling this together, Carmelo.

>Comments?
>
>     1) Which specifications is this test about, XSLT or XPATH?
>     2) Which section or area of the specification this test is addressing.
>     3) The category of this test (if any).
>     4) The test name.
>     5) The nature of this test (positive, negative, 
> implementation-defined, etc) .

I'm not sure what you mean here.  I thought that the configuration instance 
would pull out of the normative collection that subset wherein all tests 
would be positive and that a negative result in any test would indicate 
non-compliance with the configuration's claim for compliance for a 
particular area.

>     6) The expected output to this test (if any).

Do you mean prose, here, or actual markup?

If we had transformation tools that supported XInclude we could point to 
the result markup files as if they were text files and have their content 
displayable.

>     7) How do I run the tests?

Is this David's scenario concept?

>     7) Description of the tests.

Oh, is this the prose?

>     8) Any secondary files needed by the tests.
>     9) Any known problems with any of the tests.

Do you mean collectively or specifically with the given test.  Would a test 
that had a problem be included in the suite?

>     10) How do I interpret the results? (are they self-explanatory?).
>     11) How do I report problems with any of the tests?
>     12) Are there any holes in the test suite? (any areas that
>            are not addressed by any test).
>     13) When was this test written?
>     14) Who wrote this test?

Could this be private?

>     15) Any test that depends on another test.

I don't think we will have this condition ... each test should (I think) be 
independent.

>     16) Any test output that may be an input to another test.

I think we should can the input to all tests and not have any input be 
dependent on the result of another test ... another test's incorrect result 
might render the given test's result meaningless.  If all inputs were 
canned, all results should be definitive.

>     17) Is there a test harness available?

In the preamble, perhaps, but not the collection.

>     18) Which information do I need to provide to any of the tests?
>     19) Any optional tests?, non-applicable tests?
>
>I realize that some of these items (such as 11) may not quite belong
>in this list, but it still an issue for the committee.

Yes, and would belong in the preamble or prose associated with the suite as 
a whole.

>Some of them may not be
>as relevant (such as the author), but someone may find that
>information useful.

That might also be privileged to the submitter.  I think this is not 
germane to the result report and should be suppressed.

>I think that the committee already provide plenty
>of information for a user to adequately run the tests,  any other
>information although useful is not necessary.

Would we organize the normative set of files, then, as a collection of HTML 
files describing the project, the deliverables, the expectations, and some 
candidate scenarios for use, and then have these linked to that one HTML 
base file that is synthesized by your process reading the normative 
collection based on the configuration instance?

Carmelo, could you please consider the above and propose that collection of 
HTML files you envisage a user producing from your configuration processes, 
and what role each of them would play for the user of the configured 
suite?  Since we have some writers on the committee we might get some 
volunteers to start drafting the prose being used in these documents.  Your 
automated processes would read the combined catalogue and the configuration 
instance and produce the configured catalogue of files and associated 
documentation.

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

--
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)
Web site:     XSL/XML/DSSSL/SGML/OmniMark services, training, products.
Book:  Practical Transformation Using XSLT and XPath ISBN 1-894049-06-3
Article: What is XSLT? http://www.xml.com/pub/2000/08/holman/index.html
Next public instructor-led training:      2001-08-12,08-13,09-19,10-01,
-                                               10-04,10-22,10-29,02-02

Training Blitz: 3-days XSLT/XPath, 2-days XSLFO in Ottawa 2001-10-01/05