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: Re: Halfway to genericizing the test case catalog



Just a quick overview of the tactics here. A detailed response will
come later.

Ken suggests that we always control the Title of each submission. (That's
the name of the entire submitted bundle, and the name of the directory in
which it sits.) I'm okay with that, as long as we agree to respect the
submitter's wishes where practical. And I agree that we should prohibit
spaces, among other characters. SuiteName is no longer in the design.

The Source (a name from Dublin Core) is the name of a test case. Often,
one can build the input filenames from it, like <Source>.xsl for the
stylesheet. For flexibility, the Germanium Man design always allows
specification of all inputs by full name, and relative path if needed.
We do need to discuss one aspect of the path question: would it be
better to start at the top of the submitted tree or where the
stylesheet was found? For example, If the stylesheet references
document('../Utility/alpha1.xml'), then the catalog could have an
input-file element that specifies the same relative path
  <input-file>../Utility/alpha1.xml</input-file>
or specifies the path down from the <Title> directory
  <input-file>Utility/alpha1.xml</input-file>
I prefer the former as being less error-prone. These input-file
elements are real files, whereas <Source> could be just a string for
logging, unless the particular testing regime makes it attractive to
generate filenames off <Source> by default.

Identifier expresses the whole path to where some file about the test
case is found. The <scenario> helps determine what type of file to
expect. Presumably, there is something about this file that makes it a
test case different from all others.

The idea of having categories, whether they are mandatory, and whether
"Mixed" is allowed as a category are all decisions to be made by each
committee that adopts this design. Sorry if that wasn't clear.

The <elaboration> element is the best example of data that is strictly
for human/language expression. The machine merely displays it and never
makes any decisions based on its content.

I hope that's enough so that Ken can make more progress.
.................David Marston



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


Powered by eList eXpress LLC