Re: discussion of LC comments on Extensions

At 03:09 PM 4/25/03 -0400, Lynne Rosenthal wrote:

>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.

I have made an alternate proposal, which has been linked from the issue 
list for some time:

http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0026.html

I disagree that we should "tone it down" -- extensibility is #1 on my 
interoperability list of evils.  As I said in my proposal, I think we 
strike a decent balance.  (See also issue #15, where we are complimented on 
GL9).  I would not object to some verbiage about "times and situations 
where extensibility may be valuable or deemed necessary."

But I have yet to see an example where extensibility doesn't hurt 
interoperability.

Bottom line.  I don't want to ignore any legitimate positive sides, but I 
also don't want to dilute our message too much.

(Btw, I am seeing in SVG the first negative fruits of the happy "pluggable 
extensions" attitude.  At least one big SVG implementor is despairing of 
the interoperability mess that's developing.)


>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.

I agree with this.  The reminder doesn't hurt.  Not every reader is going 
to logically connect the dots, as has the commentor.


>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

Useful?  Hmmm.  I need to think about this one.  As I understand the 
comment, it this does not seem to be talking about extensible CSS 
content.  But rather about what browsers should do when encountering 
unknown stuff (which could be private extensions, corrupted or erroneous 
content, etc).


>(2) Add CP to require specs to specify how an implementation should handle 
>extensions it doesn't understand  e.g., ignore and continue.

Disagree.  We do not have the domain expertise, across W3C technologies, to 
say what is the best response.  In some critical applications, HALT is the 
best response.  This should be the purview of the individual spec.  In 
fact, maybe the individual profile of the spec.  (E.g., what you want to do 
when you encounter such a situation in an air-traffic radar application is 
probably different than what what you want to do when browsing blogs.)


>  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 Monday, 28 April 2003 10:51:25 UTC