Re: Names of test cases (Was: Halfway to genericizing...)

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

At 01/07/09 00:30 -0400, David_Marston@lotus.com wrote:
>1. Every single iteration from Straw Man through Iron Man was built in
>such a way that the submitters do not have to re-arrange their
>directory structure. In no case do we ever "flatten out" the directory
>structure, we just build a directory one level up and populate with the
>union of all the directories from all the submitters.

I apologize then, David, that I misunderstood this comment you made which 
was the basis for my interpretation:

>At 01/07/08 19:24 -0400, David_Marston@lotus.com wrote:
>My preference for an
>outer <test-catalog> element after the merge, with all <test-case>s
>being its direct children, is based on wanting to present a truly
>merged test suite.

I thought with the above you were advocating flattening out every 
submission into a single result.  I'm sorry.

I certainly agree that we need our merge container element to just contain 
the submissions as supplied, supplemented as we need to with our information.

>2. The catalog can be flatter in structure than the actual directory
>structure because the Identifier element gives a file-path from the
>submitter's top directory down to where the "primary" input file is
>found. Other files may need to be located by relative pathing from
>there. (The "primary" files varies with the "operation" value.)

Yes, it may be, but are you saying it "shall be"?

>3. We agree on the need to plan for all uses of the catalog data:
> >Please talk this over on Wednesday thinking about how the tests will
> >be identified in all uses, not just the submitter and not just the
> >merge.
>
>4. We clearly disagree about forcing a uniqueness rule on the
>submitters. I said
> >>If the submitter has a sub-directory structure, they may not have
> >>made the Source strings unique across their entire suite. We don't
> >>force them to rename their individual cases....
>and I showed an example where the files could be named "test001" in
>different subdirectories. Ken wrote
> >I feel strongly the Source be unique for each test across a
> >submitter's collection....
>but he's saying that so that Title_Source will be unique. I think I
>have a solution.
>
>Earlier, I wrote
> >>The combination of Title and Identifier will be unique within the
> >>merged test suite. [Title/Identifier, specifically]
>
>To which Ken replied:
> >Yes, but it is not lexically valid as an identifier for hyperlinking
> >purposes ... it isn't a name token.
>
>This hyperlinking requirement wasn't clear enough to be directly
>represented in Iron Man, but the solution is to form the unique
>string
>Title/Identifier
>and then map all "/" characters to "_" for the hyperlinking.

Historically in document processing, arbitrary renaming has had problems 
which is why I've always avoided it.  How do we know the convention the 
user has already used with "_" and that this translation isn't going to 
introduce ambiguity?  This has been done over the years in SGML processing 
of information related to filenames, and the most successful results have 
incorporated the source identifiers untouched.

I dislike the new length of the unique identifiers, but accept they have to 
be this way if we accept the premise described by David.

If it is true that a submitter has actually reused the same file names in 
two different directories to mean two different concepts or constructs, 
then we are forced into such an approach.  My recollection of XML 
Conformance is that every test from every submitter was uniquely named 
within each collection.  I had assumed this principle would be followed by 
all submitters.  I may not be recalling this correctly, though.

However, I will stop insisting as it is taking far too much time.

>Given that some organizations haven't shown any inclination to send
>in tests, and others have sent uncataloged tests on an as-is basis,
>I think we should not be imposing more requirements like renaming.

Sorry, I thought it was a given that submitters would have used unique 
names and that was the basis of my entire argument that making something 
already unique by adding something unique was unnecessary.

>We need to make submission of a test suite as painless as we can.
>Renaming is avoidable.

Not if the submitter is already using "_" in their file names (which is a 
legal name character) and an ambiguity is introduced by our arbitrary renaming.

Only if we have evidence submitters have actually reused the same name for 
two different tests with different purposes.  I assumed we wouldn't.

So, end of story: we go with David's technique of long identifiers 
incorporating "_" in place of "/" as the unique identifiers in the merged 
catalogue for each test.  We'll judge the feedback on this technique from 
those who review our work.

I don't see this changes the prototype catalogue-validation code for 
Wednesday, unless perhaps we flag a warning if the user has already used 
"_" in a filename.  I think not as why worry unless it actually does 
produce a problem in the end result.  If any changes are desired, please 
let me know in time to make the changes.

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