Re: Notes about name management, and questions not yet resolved

[David_Marston@lotus.com]

I agree with most of what Ken wrote. In this message, I'll just
clarify a couple things.
>> is my original message
> is Ken

Ken likes the idea of delivering the reference output in a parallel
tree. On July 11, the Committee mildly endorsed the idea of giving the
labs raw output as well as the InfoSetized output we are committed to
provide. The lab has to create the canonicalized form of those files,
plus get the test-run results in raw, InfoSetized, and canonical form.
We could steer them in the direction of separate parallel directory
trees for each, which would allow filenames to be exactly the same.
Even if they're allowed to be the same, the lab may choose not to do
that. Furthermore, Kirill has brought up the idea that the catalog
might have *elements* like <i-output-file> alongside <output-file>!

Before deciding what you want to do, consider the convenience of
having a filetype-extension-tag, or whatever you call it, notably
for launching an app to view the file. If all InfoSetized and
canonicalized files are in XML anyway, do we want their name to end
in .xml?

If raw, InfoSetized, and c10ed files get mixed in a directory, then
some systematic naming differentiator is required. Kirill showed
us a prototype that uses prefixing, as in i-casename.xml for an
InfoSetized file. Before that, we had only been thinking about
suffixes. Even if we start modifying names this way, we still have
enough data in the test-case catalog design to allow the labs to
build the names, as long as the prefixes and/or suffixes are fixed.

Clearly, this is an area that will require some form of
sequential canvassing to elicit any detectable consensus! In later
messages, I'll try to do that. Consider the Q4 and Q5 of the original
message to be highly-condensed representations of what will be asked.

>>A test lab will need to get the Title for each test case, which is
>>most convenient
>>if it's a datum within each test-case element in the merged catalog.

>I don't think it is onerous to get it from an ancestral attribute.

True enough. We still need to define our expectations for the lab's
skill levels in XSLT. When we ask them to do something that is
above the expected skill level, we should give them an example
stylesheet.

>>7. Should the file-path element have a leading slash? Trailing slash?
>"Neither?"

This is meant as two independent questions. Thus, there are four
possible renditions of file-path, and we must choose one:
a. sort/alpha/en
b. /sort/alpha/en
c. sort/alpha/en/
d. /sort/alpha/en/
In this example, a stylesheet might really be located at
OASIS-XSLT-conformance/submitter/sort/alpha/en/test001.xsl
after the lab unpacks the suite into their OASIS-XSLT-conformance
directory.

>>13. To what extent should we provide guidelines to submitters about
>>the current directory at the time the test is run? We can anticipate
>>that test labs will want guidelines from us.

>Really? My gut reaction is this is out of scope. How tests are run are
>up to the lab. Perhaps the only guideline is to ask submitters not to
>use absolute URLs when referring to files.

My apologies to your gut. Thinking as a software tester, I want to
know: how can I be sure about where the import/include and document()
references will be interpreted? If I invoke the test as
XSLT submitter/sort/num/test001.xsl -in submitter/sort/num/test001.xml
instead of CDing to submitter/sort/num, will it still work? If we give
no such guidelines, are we leaving them to grep for document( etc. in
every test?

>>14. If a submitter wants to update their test suite,...
>I think this can be deferred.
I'll respond to this separately, because it impacts the Submission
Policy.

>I would hate to waste development time
>prototyping an apparent agreement only to find late opinions
>swaying the outcome.

That's been a problem for this Committee, so speak up in a timely
fashion! (Lurkers who do QA work should speak up, too!) Thanks for
reading all the way down to the bottom.
.................David Marston