[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Submission & Review Policies
At 01/07/20 09:57 -0700, Cris Cooley wrote: > > >Essentially in an atomic test one failure points out one > > >bug. > > > > Instead of "bug" perhaps "problem" or "failure to conform" or something > > better ... I wouldn't want to necessarily claim it is a bug (and it is a > > bit derogatory) if it were a design decision (though not very > > wise) on the > > implementation's part. > > > >How about "non-conformance"? Sure. > > >8. The Submitter must provide a unique test identification > > >(ID) for use by the Committee. > > > > Actually, we will set that ourselves. > > > > The submitter is welcome to send any collection of files in any > > subdirectory structure. The root subdirectories of the submitter's > > directory structure will be subdirectories of the committee's collection. > >I'm unclear, Sorry ... I don't think the submitter gets to choose or even needs to know what ID we choose for their submission within our collection, or how we use it. I think we needn't mention internal processes in the external policy document for fear of locking out our opportunity to make changes. I'm talking about the test collection, not individual tests. I want to encourage submitters to use unique IDs for their individual tests, though David's evidence that we cannot rely on this means they needn't follow it. We will make individual tests unique by incorporating the subdirectory in the unique identifiers. But, if we encourage uniqueness, our end users will have an easier time distinguishing the tests by their simple name. If we don't say in our policy document what we do with information, just state the constraints we need or practices we desire, we will have the most flexibility. > > >9. The Committee will create a directory tree of test > > >cases, based on the Submitter's ID [?right?] where the > > >first level down the tree separates out the tests by > > >Submitter. > >I had no comments that #9 is incorrect, so I'll remove the square bracket >question. But further to my point above, should we just remove it? > > I see you have a combination of policy issues and logistics. Should we > > split the above into a short set of immutable policies and a > > longer set of > > pliable logistics that we figure out over time? > >I agree that we have logistics and policies mixed. From a submitter's point >of view it would be easier to have one paper saying 'here's what you should >and shouldn't do' (the Submission Policy) and another saying 'here are the >instructions for submission' (a User's Manual?). I can see both a "yes" and "no" answer. It would be nice to keep things together, but do we limit flexibility? However, since our logistics will change more often then our policies, could you please introduce a third document which is a Submission Manual and refer to it from the Submission Policy? Thanks, Cris, .................... 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