- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Wed, 10 Nov 2004 08:58:15 -0500
- To: www-qa-wg@w3.org
- Message-Id: <6.0.0.22.2.20041110085603.01c5ff48@wsxg03.nist.gov>
Assignment: rewrite 4.3C extensions don’t break conformance Thinking about this, I’ve concluded that there are 2 aspects: 1. The extension mechanism should be designed so that extensions are created that don’t break (TAG uses interfere) with conformance 2. Include in specifications a warning that extensions don’t break conformance (compatibility) So, I am adding new text to 4.2B define an extension mechanism to cover #1. And, for 4.3C, I’m changing this from a principle to a GP since, 4.2B is a GP and also, I don’t think we should make putting a warning into a specification a requirement. 4.2B What does this mean? Add at the end Design the extension mechanism to allow for the creation of extensions that do not interfere with conformance to the original specification. 4.3C Change Principle to Good Practice Warn implementers to create extensions that do not interfere with conformance What does this mean? Include in the specification a warning to those who are creating extensions that extensions should not contradict or negate conformance to the original specification. Why care? This is probably obvious, but sometimes it makes sense to reinforce an important point. The intent is to uphold conformance regardless of whether there is an extension or not – if it conformed without the extension, then conformance should hold true with the extension. Techniques: (no change) Examples: Karl – can you add an example from CSS3 – background color property could be legally ‘redefined’ by creating a new moz-background-color, but spec could require this should not modify the defined behavior.
Received on Wednesday, 10 November 2004 13:57:51 UTC