[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: 0.6 of the way to genericizing the test case catalog (Was: Halfwayto...)
At 01/07/06 17:09 -0400, you wrote: > >I agree that *every* test will have <Source>.xsl ... if anyone can > >think otherwise, please let us know. > >There are tests whose input is just an XML file with XSLT directives >embedded in it. Could we not adopt the convention that a simplified stylesheet still has to have the .XSL extension? I guess not if we don't want to change the submitters' files. >More on that in the "generating scripts" discussion >below. > > >Thanks for the clarification ... so, [Identifier] doesn't include > >leading or trailing "/" and we will arbitrarily add it on ourselves > >between <Identifier>/<Source>.xsl > >At our June meeting, we decided that <Identifier> would include ><Source> at the end, and hence would have that / between. Then I still have the problem of determining the subdirectory in which the source file is found. I think that is going to be important for file management. >I didn't >picture it as having a leading / for reasons that will become clear >below. I didn't picture that either as it is relative to the base of the submitter's directory. > >I gather that if no ... <output-file> then we assume > >... base the name of the output file as > > <Identifer>/<Source>.xml or <Identifer>/<Source>.htm or > > <Identifer>/<Source>.txt based on the compare= attribute? > >That was the plan, other than the part about /<Source> being explicit, >but there could be a loophole when multiple output files are involved. >(I think there isn't, but review would be beneficial.) The Test Lab will >want to isolate the outputs to a separate directory, which could be ahead >of <Identifier>. All other outputs must have a name that includes the >filetype tag, What is the filetype tag? Should we add a compare= attribute to <output-file>? I just did in my local copy of the prototype. That means, I think, that we *don't* need the attribute in <scenario>, so I've removed it. If a file is produced that doesn't need to be checked, then another committee can add a compare type of "ignore" to their list of types. >so the type of compare for those others must be based >on the tag, or else we'll have to revise how compare works. Does >anyone want to speak up for the Macintosh community, where the idea >of filetype is more elaborate? Maybe I'm confused ... you are referring to O/S issues here ... I thought we would be more concerned with confirming the content of the output. > >>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'm agreeable to allowing a fixed set of markup elements, but that's easy >for me to say, because none of the elaborations in Lotus/Xalan test cases >use markup. Great, then why don't we just use a small set such as <p>, <em>, <strong>, <br>, <ul>, <ol>, <li>, <code> and <samp>? When submitters create the OASIS catalogue from their resources they can limit it. This list is close to the Cowan list for the earlier cited IBTWSH DTD. >GENERATING SCRIPTS I'm wondering if this is out of scope. I agree we should summarize all of the inputs and outputs, but think we should leave it to the test lab to work it out. I do not agree we should supply a Java invocation sequence ... perhaps just a generic "run" batch file as that invocation will work for both MSDOS Command Line and Linux environments and could choose to run Java if desired for the tool being tested. >Think about this, because we >want to ensure that the catalog has all the right pieces that a Lab >would need to keep outputs from several test runs well organized. Sure, but can't we have a Lab tell us it cannot be done? I would rather focus our energies elsewhere. ................. 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