Re: Dave's comments and multi-dimensionality: Given that either 1) it's only a small number of tests, or 2) it will become very multi-dimensional with different processors, options, languages, etc. etc.; do we want to either:
-- agree on basic principles to get the job done for existing committers to test Xalan releases, and let the committers who will actually perform this work finish the details and implement a working system, or -- agree that we're trying to solve a bigger problem now - one of generalized XSLT conformance testing, possibly to share with outside groups - and restate some of our overall goals? While I hate to invent partial solutions that will need re-work later, I also want to make sure we are focusing on the same goal. Ensuring that the xml-xalan project is of high quality and is very standards compliant is a goal I think we all agree on. If we're *also* thinking of building Apache-sponsored donations to OASIS or the like for generic detailed conformance testing - both tests and potentially automation methods - then we should be explicit about that and get buy-in to the larger goals as well. ---- Oh, and Re: CVS tagging: everything under xml-xalan/test should IMO get tagged with the same tags as each official xml-xalan release; this is not driven from a conformance viewpoint, but from a practical viewpoint so that we can reproduce test results later. These tags should never be moved to newer file versions. If we also want to keep additional sets of CVS tags around that show which conformance test gold files matched which set of errata for which version of a product, that's fine too; just keep these tagnames separate from release tag names. ===== - Shane <eof .sig="'When I use a word,' Humpty Dumpty said, in a very scornful tone, 'it means just what I choose it to mean - neither more nor less'" "Oohayu oyod?!"=gis. /> __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
