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



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.

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

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.

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. 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.
Identifier captures the rest of the directory structure.
The combination of Title and Identifier will be unique within the
merged test suite. 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.

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?

Most of the rest of Ken's last message applies "Title" to what has been
called "Source" up to now, so I'm just responding to those parts of the
design ideas that are independent of terminology.

Ken is advocating that the merged catalog have an encompassing outer
(document) element when he says
>When we do the merging *we* will be assigning the unique name for each
>collection...and assigning that
>to the copy of their document element in our merged catalogue.
I think that will work. The merged catalog has a document element of
<master-catalog> or similar, possibly with a Date attribute (for the
OASIS point of view), and then contains numerous <test-catalog>s that
conform to the galvanized form of Iron Man. (Later: Steel Man!) The
placement of the Title, whether attribute or child element, whether
one per <test-catalog> or "pushed down" into every <test-case> element,
should be decided by practical considerations. 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.
.................David Marston



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


Powered by eList eXpress LLC