LC-81 & 101 -- extensions leftovers

At the extensions-group teleconference [1], we weren't able to reach 
consensus on CP9.6 [0], which says that specifications that allow 
extensions must require that implementations provide a no-extension mode.

There are two issues about CP9.6 -- LC-101 and LC-81.  It was proposed in 
telecon to remove CP9.6.  I was opposed.  Basically, there was a reason 
that it was in there, and the arguments for its removal seemed to me to be 
based mostly on expedience and satisfying complaints, but without 
considering the merits of the complaints versus the value of the CP.

LC-101:
-----

Earlier, I wrote a rebuttal to LC-101 [2].  As I reread LC-101 (and my 
rebuttal), I now see that Originator has misunderstood the checkpoint.  He 
says, "There may not be any alternatives (interoperable or otherwise) to 
the use of a particular extension, and in particular, it is completely 
impossible for any specification that permits extensions to supply a 
workaround to the use of every uninvented extension imaginable."

This is not what CP9.6 says.  CP9.6 says that specifications that allow 
extensions must contain conformance requirements that require 
extension-supporting *implementations* to provide no-extensions modes.  It 
does not say, as originator asserts, that the specification must spell out 
workarounds for all possible yet-to-be-invented extensions.

Originator then goes on to say:  "In other words, no specification that 
allows extensions can conform at priority three, ever."  This is incorrect, 
based on the original misunderstanding of what CP9.6 says.  Target 
specifications can conform (to this P3 checkpoint) if it requires a 
no-extensions mode of conforming implementations.  Implementations can 
conform to target specification (or not) by offering the mode (or not).

LC-81:
-----

I am the Originator of this issue.  As I thought about our motives for 
CP9.6, it occurred to me that what we are really trying to do (at Priority 
3) is to mitigate the interoperability downside of extensions, in those 
implementations that support them.  Right?  (Or wrong?).  A no-extensions 
mode is one way to do this.  But there are other ways.  For example, an 
implementation could also offer a mode in which alternative, equivalent 
standard content is included along with the extension, similar to the 'alt' 
of HTML.

Proposal.  Either:

1.) Leave CP9.6 as is (i.e., reject both LC-101 and LC-81);
2.) or, revise CP9.6 to reflect the real motive, mitigating downside of 
extension-supporting implementations (i.e., reject LC-101, accept LC-81).

Regards,
-Lofton.

[0] 
http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Ck-operate-without-extension
[1] http://lists.w3.org/Archives/Public/www-qa-wg/2003May/0039.html
[2] http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0028.html

Received on Monday, 2 June 2003 10:19:47 UTC