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: Onward to Design Questions #2 and #3 (Action Item for TC)


Okay, we inched toward consensus that the correct-output files would be
delivered in a directory tree that is parallel to the tree of test cases.
That opens the possibility that the names of output files can match all
the way to the tag/extension between actual and reference output. The
next set of questions concerns this naming scheme.

I sense that we want to deliver both raw and InfoSetized reference
output, based on remarks at the July meeting and since. The InfoSetized
is required for comparison, while the raw is a convenience to help the
test labs see that they are doing the processing correctly. If anyone
objects to sending both, speak up now because follow-up questions will
assume we send both.

Committee members: consider this a canvassing operation. I'd like to
see how close we are to consensus, but also get your reasons why you
hold the opinion you do. If you have no opinion, please respond anyway
and say you have no opinion. All responses to the list, and use the
"Reply" feature if at all possible, or otherwise indicate that your
message is a response to this particular item. (Other design-decision
threads will be started later.)

Terminology note: When I introduced the topic in my "Notes about name
management, and questions not yet resolved" message of July 13, I used
the terms "primary" and "secondary" to refer to input and output files.
I have since learned that the XSL Working Group is likely to use the
word "principal" rather than "primary" for the same purpose, so I'm
making that same change as of now.

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.

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

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



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


Powered by eList eXpress LLC