W3C home > Mailing lists > Public > www-qa-wg@w3.org > November 2004

SpecGL: rewrite 4.3C extensions break conformance

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Wed, 10 Nov 2004 08:58:15 -0500
Message-Id: <>
To: www-qa-wg@w3.org
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.

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.

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 

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.

(no change)


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:33 UTC