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

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

At 01/07/18 20:14 -0400, David_Marston@lotus.com wrote:
>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>!

I hesitate to ask the submitter to consider names of infosetized outputs 
(what if our methodology changes in the future?).

>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?

Good point!  All of our infosetized files are in XML.  How about when we 
add the parallel directory structure and the infosetized output files we 
use the *additional* file extension of ".xml", thus:

  /submissions/Lotus/numbering/numb06.xml
  /submissions/Lotus/numbering/numb06.xsl
  /submissions/Lotus/numbering/XOUT/numb06.out
  ...
  /submissions/Acme/html/html02.xml
  /submissions/Acme/html/html02.xsl
  /submissions/Acme/html/html02.htm
  ...
  /infosetized/Lotus/numbering/XOUT/numb06.out.xml
  ...
  /infosetized/Acme/html/html02.htm.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.

Again, I am sensitive to making assumptions about the names.

> >>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.

Oh, I was expecting to have some examples as part of Carmelo's end-user 
package.  The end-user (labs) are seeing all our information through 
Carmelo's presentation/packaging/examples/configuration-scripts.

> >>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.

Again, I feel the fewer the better, *just* in case.  Perhaps, we can even 
undertake the extra processing to trim the first and last if they are '/' 
and then rebuild it (though that violates my earlier principle of touching 
the submissions as little as possible).  This processing only happens once 
by us, and not by the user of our final collection, so we could incur the 
overhead.

> >>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?

Can we cover all (enough?) of the cases?  If you feel it can be done 
acceptably, then I won't stop you from having it added ... it just seemed 
to be the thin edge of a wedge to me.

..................... 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