Re: Onward to Design Questions #2 and #3 (Action Item for TC)

[Lofton Henderson <lofton@rockynet.com>]

At 04:38 PM 8/14/01 -0400, David_Marston@lotus.com wrote:
>Okay, we inched toward consensus that the correct-output files would be[...]

Do we have an alternate terminology for "correct-output", such as 
"Reference Output"?

>Design Question #2: How should filetype extensions be used on the
>raw output files and the corresponding correct-output files?
>This question only applies to the principal output, since all secondary
>outputs would be named directly in the stylesheet. (Actually, there is a
>subsidiary question about console log files. We probably don't have to
>pick a naming scheme for those.) There are two possibilities here:
>A. All principal transformation outputs have the same extension, like .out
>(actual to be determined in a later question), regardless of whether the
>file is text, XML, or HTML.
>B. Principal transformation outputs have an extension pertaining to the
>type. Exact extension tags are to be determined later, but the old
>favorites would be .xml for XML, .html or .htm for HTML, and .txt for
>text.

I have a mild preference for "B".  If the information is available, 
exposing it can only be helpful in both assembling and using the test 
suites.  It would seem to help reduce the possibility of errors and 
confusion, and I can't see any big downside immediately.

However, looking at Ken's prototype-3 (collcat.dtd), and considering Ken's 
vote for his new "C", I'm a bit confused.  Sorry if this is obvious and I 
missed it -- I have been trying to absorb lots of stuff in catch-up mode 
this week -- but is there any current definition of "output-file", and is A 
or B (or C) is superseding that definition?  Or rather, is this canvassing 
providing our initial definition of "output-file"?


>Design Question #3: Should the canonicalized and InfoSetized outputs
>be distinguished by naming, directories, or both?
>This question applies to both principal and secondary output files, but
>not to log files. We won't deliver the final-stage canonicalized form,
>but we can anticipate that most test labs will follow our precedent.
>Assume that this question also applies to both the supplied "correct"
>output and the generated output, though we mainly control the former.
>There are three possibilities here:
>X. Additional parallel directory trees hold the canonicalized and
>InfoSetized versions of the outputs, but filenames are exactly the same.
>Only the directory at the top of the sub-tree distinguishes the file.
>Example: output-raw/x/y/numbering01.out after InfoSetizing is stored in
>output-infoset/x/y/numbering01.out.
>Y. Additional parallel directory trees hold the canonicalized and
>InfoSetized versions of the outputs, and a naming scheme distinguishes
>the files. The scheme could be a prefix, suffix, or altered tag, which
>will be determined later. Example: output-raw/x/y/numbering01.out after
>InfoSetizing is stored in output-infoset/x/y/numbering01.iset.xml (all
>InfoSetized files are XML, regardless of source).
>Z. A naming scheme distinguishes the files, but they are in the same
>directory. Example: output/x/y/numbering01.out after InfoSetizing is
>stored in output/x/y/numbering01.iset.xml (note same directory).

My preferences are, in order:  Y then Z.  I can also live with X.  But I'm 
not a big fan of two files having the same name if their contents are 
conceptually different, even if the names become unique when fully 
qualified by path within parallel directory trees.  Even though the 
fully-qualified names suffice, in principal, in the expected operational 
context ... things have a way of migrating (or wandering) out of context.

Regards,
-Lofton.


>Reminder: below are some considerations that you may use as the basis for
>your choice:
>+ Ease of test lab locating files when comparing
>+ Ease of test lab organizing storage of test-run results
>+ Ease of cataloging and/or need to change catalog design
>+ Ease of submission and creation of reference files for submission
>+ Likelihood of naming conflicts between submitter and OASIS
>+ Uniformity of merged catalog vs. submitter creativity
>+ Likelihood of errors, either by Committee or test labs
>+ Impact of changing submitter's filenames or directory names
>+ How the test lab will invoke their comparison tool
>
>PLEASE RESPOND RIGHT AWAY! We have more questions to settle by August 21!
>.................David Marston
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: xslt-conformance-request@lists.oasis-open.org


*******************
Lofton Henderson
1919 Fourteenth St., #604
Boulder, CO   80302

Phone:  303-449-8728
Email:  lofton@rockynet.com
*******************