- From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Date: Tue, 28 Jan 2003 12:53:06 -0500
- To: Dominique Hazaël-Massieux <dom@w3.org>
- Cc: www-qa-wg@w3.org
The new verbiage isn't working too well for me. One part is that I don't think all readers will take "factorize" to mean the same thing. Perhaps the rationale could focus on the test suite.... 1. Being a discretionary item means that different implementations can do different things. 2. Can still have test cases for each of those things. 3. Test lab needs to know which choices were made, etc., in order to know which conformance test cases apply. 4. Even if the user gets to make a choice (say, by API argument), the test lab still needs to know how the user does it, so they can test all available behaviors. 5. If spec doesn't want implementation to pass through choices to user, and the nature of the discretionary item makes it feasible, need explicit verbiage to say implementer must choose. 6. Test lab that wants to test multiple implementations needs to know that there is parity or substitutability across the alternatives, and when one discretionary item applies only if a particular choice was made on another item. 7. Discretionary items might only apply to certain modules, levels, or profiles, which should be stated in spec. We also need something about bundling. Stated in a positive way, one bit of discretion (e.g., how strictly to enforce schema typing) may be a global choice for the implementer that is mentioned in many parts of the spec where it has individual consequences. A spec that has the scattered parts and does not bundle them into a single policy-level discretionary item should fail this checkpoint. This "consistency" test requires good wordsmithing. .................David Marston
Received on Tuesday, 28 January 2003 12:56:14 UTC