W3C home > Mailing lists > Public > www-qa-wg@w3.org > April 2003

discussion of LC comments on Extensions

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Fri, 25 Apr 2003 15:09:21 -0400
Message-Id: <5.1.0.14.2.20030425150455.01c44e08@mailserver.nist.gov>
To: www-qa-wg@w3.org

Discussion topic for Monday's telecon or a later telecon
Most of these are relatively simple, compared with other LC comments we 
have dealt with.....

Editorial or minor

LC-52, 73.5, 75.4:  NOT! in G9
NOT! seems out of line with the rest of the document, change to “Not” or 
something else?

LC-100: don't discourage extensibility.
The position of the QA framework WG, that extensions should not be allowed, 
is quite clear.  This doesn't accommodate those working on specs that 
clearly demand public extensibility.  The document should describe 
conformance not discourage extensibility.
Discussion:  The SpecGL includes several cautions regarding the affect of 
extensions (and other DoV) on interoperability.  Perhaps we go overboard.
Proposal: Tone it down, in GL9, there are 2 places in GL9 explanation with 
cautions; also include something about the usefulness of allowing 
extensibility.  Make the last paragraph the beginning. (See also LC29.5 below.)
The new Concept chapter will have a DoV caution and we agreed(?) that each 
DoV would have a simple caution statement.

LC-38: Combine CP9.1 and 9.2,
LC-73.6: Improve wording of 9.1  (now moot)
We already agreed to this, since 9.1 is a subset of 9.2.  Text will be revised.

LC-35,37:  Delete CP9.3 extensions can not contradict the 
specification.  Basically, this states the obvious.  Also delete the 
corresponding sentence in 3.2, “…this spec MUST not contradict…”
Discussion: Yes, it may be redundant, but some people don’t think about the 
consequences of extensions, so this is a good reminder.
Recommend: leaving these statements as is.

More technical

LC-29.5: Say more about useful ways of allowing extensibility (e.g., CSS’s 
forward-compatible parsing, HTML, and XML), about what to avoid, and is the 
general practice of ‘ignore what you don’t know’ good or bad.
Discussion: This is asking for more specific information.  The new Concepts 
section could address some of this as well as ExTech.  Other than the 
general statements about extensions inhibit interoperability, is there more 
specific things we can say should be avoided?
 From CSS Level 1: “It is expected that higher levels of CSS, with 
additional features, will be defined in the future. To ensure that UAs 
supporting just CSS1 will be able to read style sheets containing higher 
level features, this section defines what the UA does when it encounters 
certain constructs that are not valid in CSS level 1. “
Proposal:
(1) Add text about useful ways to allow extensibility in G9 explanation 
and/or Concepts chapter.  Add CSS, HTML, XML etc examples in ExTech under CP9.1
(2) Add CP to require specs to specify how an implementation should handle 
extensions it doesn't understand  e.g., ignore and continue.

  LC-81, 101: CP9.6 alternatives to extensions
Requiring an operating mode under which only strict-conforming content may 
be produced may be too narrow a requirement.  Is the intent of the CP 
satisfied if an implementation generated strict-conforming ‘alt’ content to 
a private extension?  Why include an extension at all, if the ‘alt’ content 
is “equivalent”?
There may not be any alternatives to a particular extension or it may be 
impossible for a specification that permits extensions to supply a work 
around.
Proposal:
1. ‘Alt’ mechanisms that contain only strict-conforming content and achieve 
equivalent effect, should qualify.
2. Remove the CP
Recommend: Remove the CP. We argued this before, I think it has a very 
limited application.

LC-97: Modules as extension points.
????
Received on Friday, 25 April 2003 15:09:41 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:13 GMT