OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xslt-conformance] Thoughts about simplifying the test case cataloging






At our last teleconference, we discussed whether some cataloging
requirements could be relaxed, in case complexity of the catalog is seen
as discouraging submissions. Some of the data in the catalog is already
optional, so there are only a few required items that can be omitted
without impacting use of the tests. I'll put each data item in one of
three buckets, ranging from optional to required.

Only items that apply to individual <test-case> elements are discussed,
because the cost to provide higher-level data about the submission is
so trivial. The date of submission is optional from the submitter's
point of view, but we should add it into the submission when received,
so we can keep track when revised submissions occur.

ALREADY OPTIONAL
<creator>
<date>, which is good to have
<elaboration>
<gray-area>, which we may need to add in if we start depending on it

CURRENTLY REQUIRED, BUT COULD BE OPTIONAL
test-case "category" attribute
<purpose>, which helps at the review stage and also helps the test lab
   when assessing results
<spec-citation>, which can be as simple as one section number

REALLY REQUIRED
test-case "id" attribute, which is its unique name
<file-path>, which essentially is the argument to a cd command
<discretionary>, when applicable
<scenario>, with clarifications noted below:
For those groups of tests we will examine next, the "operation"
   attribute will usually be "standard", which offers some relief
<param-set> needs more review, but is probably infrequently used
<console> is optional, used for error cases and otherwise available
   but probably infrequently used

SUMMARY: most of the material that is really required follows a
pattern that is either machine-discernible or easily cut-and-pasted
in a file editor. One hopes that the tests have a comment that can
be readily extracted for the <purpose> value, so that this useful
information will not be sacrificed. Some of the material is only
"required when it's needed" but should be noted as required, just
not for every case.
.................David Marston



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC