Proposed reply Re: answer to TAG issue on SpecGL ICS

Le mardi 03 mai 2005 à 19:48 +0200, Chris Lilley a écrit :
> KD> 7) No extensibility mechanism
> KD> We disagree that SpecGL doesn't define an extensibility mechansim. In
> KD> section 4.3 (Extensibility), we say that one can extend SpecGL as long
> KD> as it doesn't negate the requirements given in the specification. This
> KD> is a basic extensibility mechanism, and we don't think at this time
> KD> there is any need for a more complex one.
> 
> Well, okay. Bear in mind then, that you can never publish a second
> edition or a new version of this specification that has any deprecated
> or obsolete features, as these would contradict the one constraint that
> you have on extending the specification. Also bear in mind that any
> third party can conformantly claim to have published version 2 of
> SpecGL.

The QA Working Group notion of extensibility does not include versioning
as a form of extensibility; as such, a next version of Specification
guidelines - should it ever exist - is not considered as an extension of
the first version, and is not constrained by the extensibility mechanism
defined in its first version.

(The QA Working Group understands that the TAG deals with extensibility
and versioning together since they have many common properties and
constraints; but in terms of conformance, this grouping is not very
relevant, since backwards compatibility is not a requirement across
versions of a specifications).

> Would a comment "We have no extensibility mechanism because we think they
> are bad" count as an extensibility mechanism in terms of SpecGL
> conformance?

Definitely; SpecGL  says first "Address extensibility", and then "if
extensibility is allowed, define an extensibility mechanism". "Address
extensibility" makes it clear that not being extensible is a perfectly
acceptable option.
http://www.w3.org/TR/qaframe-spec/#extensions

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org