[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 >stylesheet. 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 <Identifier>/<Source>.xsl >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! :{)} Thanks! ................. 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