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


At 01/08/14 16:38 -0400, David_Marston@lotus.com wrote:
>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.

I have no objections ... again, we get to keep the submission directories 
untouched and put our infosetized results in a parallel directory.

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

C. The complete name of the output file (with extension) is specified in 
the <output-file> content and is analyzed according to the compare= 
attribute value.

>Design Question #3: Should the canonicalized and InfoSetized outputs
>be distinguished by naming, directories, or both?

Parallel directories are pragmatic as I'm worried any derivation algorithm 
is potentially ambiguous, but I wonder if all we need to do is suffix the 
output name (complete with the output extension) with ".xml" and ".can", as 
in:  the submitted result is "result.htm", the infosetized result is 
"result.htm.xml", and the canonical result is "result.htm.xml.can" (or even 
"result.htm.xml.xml").

In retrospect, isn't the naming of the canonical form entirely up to the 
testing lab and all our work can end with the naming of the infosetized result?

Further (I'm thinking as I type this, sorry 'bout that), with a parallel 
directory for infosetized results need we even bother with changing or 
supplementing the filename?

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

(sorry, I didn't realize you had followed with exactly the examples I needed!)

I think we can avoid any possible ambiguity problems only by using "X".

........................... Ken



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


Powered by eList eXpress LLC