At 01/07/09 00:30 -0400, 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, 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:
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
