W3C home > Mailing lists > Public > public-webarch-comments@w3.org > October to December 2004

Re: KD013 Extensiblity

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 15 Oct 2004 15:38:56 -0400
To: public-webarch-comments@w3.org
Cc: Karl Dubost <karl@w3.org>
Message-id: <87wtxrai0f.fsf@nwalsh.com>
/ 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,

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

Received on Friday, 15 October 2004 19:39:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:48 UTC