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