[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