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

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

At 01/07/08 12:21 -0400, David_Marston@lotus.com wrote:
> >> is my prior response
> > is more Ken Holman commentary
>
> >>We could relax the requirement for the submitted catalog to have the
> >>Title element, and possibly "category" values for each test, yet
> >>impose on ourselves the requirement that the catalog we ship has them.
>
> >Then I am confused ... I thought "Title" was going to be unique identifier
>
> >given to every test by the submitter.
>
>No, Title is the identifier of the whole suite from a single submitter.

I'm sorry, David, I'm speaking of:

At 01/06/29 20:31 -0400, David_Marston@lotus.com wrote:
><!ELEMENT test-case ( Title? , Source , Identifier , Creator* , Date? ,
>   purpose , elaboration? , spec-citation+ , discretionary? , gray-area? ,
>   scenario ) >

 From your documentation above I understood you to be using Title for the 
unique identifier of each test-case.  If this isn't the purpose, where is 
the short identifier for each test case?

>Distinct Title values across all submitted suites is a crucial part of
>our naming scheme for the entire merged suite, though.

Yes, but I thought this was going to be assigned by us and added by us to 
the resulting package and not specified by the submitter.

> >The comment in your halfway document read,
> >in part, "This must also meet filename constraints: letter first, no
> >spaces, 'reasonable' length". In my prototype document I made this an ID
> >attribute as that satisfies the constraints as documented, and I made it
> >mandatory so that every test has a unique identifier.
>
>Which brings us back to the remark quoted at the top of this message.
>There seemed to be some question about whether we should have the
>submitter suggest a Title. Since they must be unique across all
>submissions, the Committee has to make the final determination of the
>Title.

Ohhhhh, now I see where the confusion lies.

No, I disagree that the submitter's authored Title has to be unique across 
all submissions *because* I plan to use as an identifier in the final 
package the concatenation of submitter's unique value, the "_" character, 
and then the Title *as supplied by the submitter*.

Thus, the Title value used in the final package *isn't* the one authored by 
the submitter, but is the concatenation *we* control.

I think it is critical we allow the submitter do use whatever they want as 
unique titles for each test case ... we can uniquify *all* of them by 
prefixing the unique prefix *we* assign to each submission.

>This leads to the idea that the Title could be specified once, at
>the top level of a submitted catalog, since it's a constant string from
>the submitter's point of view. Not so in the merged catalog!

Now I'm confused again.  If the Title is the mechanism by which a submitter 
uniquely defines every test in their catalogue, there need by no 
constraints on what is used *and* the submitter cannot just put it at the 
top of the catalogue.

When we do the merging *we* will be assigning the unique name for each 
collection, without using the "_" character in the name, and assigning that 
to the copy of their document element in our merged catalogue.  We then 
modify the Title of every test case to be prefixed with the unique 
submission name and "_" and we have uniqueness across the entire merged 
catalogue.

This is a technique I've used in my merging of unique identifiers in Topic 
Maps.

This is what I described earlier this morning:

> >In the produced
> >catalogue, the submitter's unique prefix (assigned by us) is suffixed
> >by "_" and the supplied title for the test, to ensure uniqueness of all
> >tests in the final catalogue.
>
>Now I see where clarification is needed. The merged catalog needs to
>have a Title at sufficient detail level that each case can be named
>uniquely across the whole merged catalog.

Yes, not as authored but as merged.  The authoring of the unique values 
across a given submitter's cases is controlled entirely by the submitter.

>If each submission is
>cataloged in the submitter's <test-catalog> element, and our merged
>suite is likewise cataloged in our <test-catalog> element, then the
>latter must have Title pushed down to the level of each <test-case>
>element.

Careful ... not "pushed down".  In the merged catalogue, each of our 
instances of <test-catalog> will have a <Title> child of the unique 
submitter's prefix, and then the *values* of the <Title> child for each 
<test-case> element will be modified to be prefixed with the submitter's 
prefix.  Thus ensuring all <Title> elements across the entire merged 
instance are unique.

I read from your use of "pushed down" as if the Title value was inherited 
in whole by all test cases ... since the test cases will have their unique 
Title values already the inherited value will just prefix them.

BTW, this uniqueness can be enforced by moving Title into an attribute of 
type ID instead of an element child, so I'll ask again if this can be done.

>Thus the DTD for the merged catalog could differ from the
>DTD for submitted catalogs in this regard. (Similarly for category when
>a committee wants to do its own categorizing of submitted cases.)

Yes for our added elements and no for the modified values.

>Now let's look at the filenames, using "/" notation. In the merged
>suite, every test case is identified by
>Title/Identifier
>when the current directory is the place where you unpacked the
>entire merged suite. That is, the master directory of the merged suite
>has several subdirectories named by the <Title>s of the suites that
>were submitted to the merge. The <Identifier> includes <Source>, which
>is the name of the individual test case.

Yes.  It is authored as "Identifier" and we prefix it with "Title/" in the 
merged result.  If the filename begins with "." (a simple test), it is 
relative and untouched by the prefixing.

>An actual stylesheet file is
>most likely named
>Title/Identifier.xsl
>but we need to discuss this relative to <input-file> elements. At least
>you can see why Title must meet filename constraints and why I haven't
>said anything about "_" in filenames.

I think we are in violent agreement here.

BTW, I understand there are no constraints to using "_" in filenames.  The 
submitter can choose to use "_" in their identifiers and filenames, we just 
need to exclude it from our prefixes used to uniquely identify each submitter.

>Iron Man and Germanium Man need to split the design of a submitted
>catalog and a merged catalog, or else say that the merged catalog has
>an outer <master-catalog> element containing several <test-catalog>
>elements. I've been leaning toward the former approach.

You can handle it any way you wish, but I agree we need to be more careful 
talking about the submitted instance and the merged instance.

Note that if it were test-case/@Title then the merged DTD can include the 
authored DTD and supplement the test-case attribute list declaration with 
the added attribute ... but that cannot be done if Title is an element 
child.  Yet another argument for using attributes.

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