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: Names of test cases (Was: Halfway to genericizing...)


At 01/07/08 19:24 -0400, David_Marston@lotus.com wrote:
>More answers to questions, clarifications, etc.
> > from Ken
>
> >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?
>
>That's Source. Title identifies a whole submitted suite.

Okay, then it doesn't belong in the individual test *unless* (as you say at 
the bottom of this message) you combine all of the catalogues into one flat 
merged catalogue.

I'm *really* not comfortable with combining all catalogues into a single 
flat merged result and think the structure of a submission should be 
reflected as a subtree of the merge.  A testing lab could choose to flatten 
it if they wanted to, but it would be a helluva lot of work to recreate any 
structure as submitted.

> >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.
>
>I'm saying the same thing, except for terminology. The submitter has a
>unique name for each case, within the realm of what they submit, by
>each case having a distinct Identifier, of which Source is the final
>substring. (If they have unique Source names, as Lotus does, that's a
>nicety, but we don't insist on it.) We uniquify all names across all
>submitted test suites by prefixing the Title, which we control. Thus
>there is no need to concatenate "_" with anything.

Given my new understanding of your terminology, I think the "unique 
identifier" (not "Identifier") of each test case is the concatenation of 
Title, "_", and Source.  The *need* for the "_" is to avoid inadvertent 
concatenations being spelled identically to other IDs.  In my real world 
experience of uniquifying identifiers I have always found it useful to have 
this kind of delimiter to avoid the edge cases that are theoretically possible.

>Since we don't require the submitter to make Source unique as long as
>Identifier is, it's possible for a submitter to have a structure where
>the Source names are repeated in different directories:
>   expression/test001
>   expression/test002
>   ...
>   expression/testnnn
>   sort/test001
>   sort/test002
>   ...
>In the above example, the test case Source names "testnnn" are used over
>in each directory, so we can't be assured that concatenating Title and
>Source will suffice to produce universally-unique case names.

Nope, I'm still not convinced.  Consider the synthesized HTML that Carmelo 
will be producing from the XML of the merged catalogue.  Personally, I 
would prefer that the hyperlink anchors be named "TITLE_SOURCE" rather 
than, say, the generate-id() of the nodes since that would be the only 
other way to guarantee uniqueness.  The names of hyperlinks shouldn't 
include "/" so I think Carmelo is forced into using generate-id() to make 
the hyperlinks to the test cases in all of his indexes we end up 
having.  This loses any connection or relationship to the name of the test.

I feel strongly the Source be unique for each test across a submitter's 
collection and that the concatenation I describe be used to make these 
unique across the merged collection and still meaningful.  I suspect this 
will also help in debug.

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.  Carmelo and test labs will be working with the merged catalogue in 
producing their many reports ... how will they want to identify the tests.

BTW, if we go this way we can use a validating XML processor to ensure the 
uniqueness by moving the Source value into an ID-typed attribute.

>To restate for those who aren't following this discussion in detail:
>Title is a string like NIST, Lotus, Microsoft, Sun, Saxon, etc.
>Source represents the name of a test case as the submitter views it.

I agree.

>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, nor do we force them to alter their
>directory structure.

But uniqueness is critical for hyperlinking.  We had absolutely unique 
identifiers for every test in XML Conformance and I feel this has to be 
true in the submitter's catalogue.

I'd like the opinion of test labs to my assertion here to ensure I'm not 
just out to lunch.

>Identifier captures the rest of the directory structure.
>The combination of Title and Identifier will be unique within the
>merged test suite.

Yes, but it is not lexically valid as an identifier for hyperlinking 
purposes ... it isn't a name token.

>This was part of the Wooden Man design. When you
>have a merged catalog, you need the Title for every test case. That's
>why my last message opened the possibility that the DTD of the merged
>catalog may differ from that of the submission catalog.

I still haven't been convinced.

>Too bad J.R. left the Committee. I think he had good reasons for
>introducing Dublin Core names, but the confusion over Title, Source, and
>Identifier is a direct result of using those names instead of ones that
>derived from our specific usage. In Straw Man, these were suite-name,
>case-name, and file-path, respectively. I don't think we would have had
>all this confusion if those names were still in use. However, I don't
>want to abandon Dublin Core just because one guy isn't around to speak
>up for its benefits. Anyone else have an opinion?

If we can't get it straight, our users won't either.  As you can see I've 
been wrestling with it all week.  I say we toss the DC names.

>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. If we did that, then it's clear why <Title> has to
>be present in every <test-case> element in the merged catalog.

Yes, *that* is clear, but I'm not convinced we should do it.  I think we 
should preserve the submitter's subdirectory structure and catalogue structure.

One late consideration: what if a submitter is relying on relative 
addressing to multiple input files?  Reflecting the submitter structure may 
have some semantic important to the submitter that is lost on the committee.

Can we have someone else's opinion on this?  It seems David and I have two 
different visions and strong opinions for the merge.

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



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


Powered by eList eXpress LLC