Re: KD013 Extensiblity

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| * KD 013
| 4.2.3. Extensibility
| """ Good practice:  Extensibility mechanisms
|   A specification SHOULD provide mechanisms that allow any party to  
| create extensions that do not interfere with conformance to the  
| original specification."""
|
| This Good Practice is too general. Extensibility MUST NOT be a SHOULD.  
| Extensibility is a very delicate topic which has to be considered  
| carefully by a group designing a format. It CAN be absolutely wise to  
| forbid extension.
| Choosing extensibility leads to benefits and drawbacks. See for this  
| topic
| 	http://www.w3.org/TR/qaframe-spec/
| 	http://www.w3.org/TR/spec-variability/
|
| 	1. If extensions is considered as beneficial, the specification MUST  
| provide a mechanism to do so.
| 	2. If such a mecanism is given, it MUST not interfere with the  
| conformance of the section
|
| I would add a link from this section to the QA Framework Specification  
| Guidelines and to the Variability in Specifications document.
| 	http://www.w3.org/TR/qaframe-spec/
| 	http://www.w3.org/TR/spec-variability/

We've made several of the changes you suggest. The text has been made
more explicit about the tradoffs involved and links have been added to
the qaframe-spec and spec-variability documents.

Do you find the revised text satisfactory?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.