Re: Revised Review & Submission Policy docs

[David_Marston@lotus.com]

I just want to apply a little more polish on the Submission Policy.
Someone who hasn't been in this very deeply (Stan? Norm?) should read
these documents for overall understandability.

2. The statement of purpose of a test may need to be "compound" in some
technical sense. I've just finished writing a matrix-full of cases that
attempt various nuances of changing the namespace URI associated with a
prefix or denoted as the default, and the nuances lead to compound
structures: conditions A+B+C, A+B+not-C, A+not-B+C, A+not-B+not-C, etc.
are each in a separate case. Also, I find it laughable to talk about
"a single testable assertion" in the specs, when they don't really meet
that level of rigor. I don't mind talking about testable sentences, of
which there are some, but nearly all purpose statements also have to
embody some inferences.

3. You can instruct the submitters to look inside the file xsltcfg.xml
for data about the types of pointers we recognize. Citations can be in
one or more of the formats; the more detail, the better. None of the
formats allow pointing at a sentence except when the sentence happens to
the lone sentence in a paragraph or list-item. [Background note: if we
don't find a lot of value in the XPointer-style citations in the pilot
phase, we might not see many more of them.]

4. Add a sentence that says our method for comparing results will
overcome irrelevant differences in serialization.

6. "The suite will differentiate test cases based on choices made by the
Submitter." I think we actually differentiate test cases based on the
discretionary choice(s) that the Submitter indicates as relevant, if any.
(A Submitter could actually submit separate cases for both branches of a
two-way choice.)

10. Need to qualify:
The Committee intends to retain the personal names of Submitters, if
provided, so they may get public credit for their work.
.................David Marston