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: Halfway to genericizing the test case catalog

At 01/07/06 14:22 -0400, David_Marston@lotus.com wrote:
>Just a quick overview of the tactics here. A detailed response will
>come later.

Thanks for the quick response.

>Ken suggests that we always control the Title of each submission. (That's
>the name of the entire submitted bundle, and the name of the directory in
>which it sits.) I'm okay with that, as long as we agree to respect the
>submitter's wishes where practical.

Of course.

>And I agree that we should prohibit
>spaces, among other characters.

In my prototype I used the attribute type of ID to ensure it is a name 
token (so it can be used in the final collection to uniquely prefix all of 
the test cases received from a given source.  By convention, I would like 
to preclude the use of "_" so I can suffix the prefix with "_" to ensure no 
name collisions in the result.

>SuiteName is no longer in the design.

I'm not using it in any content model.

>The Source (a name from Dublin Core) is the name of a test case. Often,
>one can build the input filenames from it, like <Source>.xsl for the

If we used a NMTOKEN attribute, we could constrain the lexical pattern of 
the value to be acceptable for use in filenames (and we can validate the 
absence of "." from the value).

I agree that *every* test will have <Source>.xsl ... if anyone can think 
otherwise, please let us know.

>For flexibility, the Germanium Man design always allows
>specification of all inputs by full name, and relative path if needed.
>We do need to discuss one aspect of the path question: would it be
>better to start at the top of the submitted tree or where the
>stylesheet was found?

I agree it should be relative to <Source.xsl>.

>These input-file
>elements are real files, whereas <Source> could be just a string for
>logging, unless the particular testing regime makes it attractive to
>generate filenames off <Source> by default.

Thanks for the clarification.

>Identifier expresses the whole path to where some file about the test
>case is found.

Thanks for the clarification ... so, it doesn't include leading or trailing 
"/" and we will arbitrarily add it on ourselves between 

>The <scenario> helps determine what type of file to
>expect. Presumably, there is something about this file that makes it a
>test case different from all others.

I gather that if no <input-file> or <output-file> then we assume 
<Identifier>/<Source>.xml and base the name of the output file as 
<Identifer>/<Source>.xml or <Identifer>/<Source>.htm or 
<Identifer>/<Source>.txt based on the compare= attribute?

>The idea of having categories, whether they are mandatory, and whether
>"Mixed" is allowed as a category are all decisions to be made by each
>committee that adopts this design. Sorry if that wasn't clear.

It was just that I saw in the halfway document it was explicit so I moved 
it from there to the configuration document.

>The <elaboration> element is the best example of data that is strictly
>for human/language expression. The machine merely displays it and never
>makes any decisions based on its content.

I agree, but my concerns are about validating the catalogue with a 
validating XML processor.  If the elaboration contains a <p> element, where 
will it be validated?

>I hope that's enough so that Ken can make more progress.

A bit.  I've inadvertently left in a namespace declaration for FO because 
of a copy/paste problem, so that has been changed on my local copy.  I 
don't have enough yet to make any changes to the copy on the OASIS site, so 
please let me know as soon as you see something you would like modified.

If I can get a lot of changes in before Wednesday, then you folks will be 
in a good position to come out of Wednesday with validated catalogues for 
the Number tests.  I can then take those validated catalogues and begin 
work on the product assembly scripts.

In the interest of saving time, I am being very naughty and bypassing 
documentation as I write.  Being a second generation programmer I *know* I 
should not be doing this, but I want to get a lot done for you to work with 
next week.  Please let me know of anything in the prototype validator you 
need changed to be able to work with it.

Hey, perhaps I can delegate the documentation of the scripts to someone 
else under the guise of "sober second thought" on the program design! :{)}


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