Re: discussion of LC comments on Extensions

[repeated on www-qa, with additional & modified comments...]

I guess this stuff will be on Monday, 5th may agenda...

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?

Yes.  Can we fairly declare these three "Resolved"?  (w/ the SpecGL editors 
suggestion to change "NOT!" to "not."

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

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 have some 
interoperability downside.

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

>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 
>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. “
>(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 
example in 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 profile is 
probably different than what what you want to do in a blog-browsing profile.)

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

I recall discussions, but not conclusions.  Any references?  (Issues 92, 
93, 106, 109 in generic QAWG issues deals with extension, [1], but not this 

I'm not ready to support "remove the CP" yet.  It basically requires that 
specifications, if they allow extensions, require that mechanisms be 
provided to mitigate the interoperability downside.  Priority 3.  So ... 
why should a spec get AAA SpecGL rating, if it does not require that 
interop downside of extensions be mitigated?

>LC-97: Modules as extension points.

Resolved today per your email of 20030418 [2], with AI for you and MS to 
work out whether some helpful wording will be in the (today agreed) 
consolidated profiles/modules/levels GL, or in section 2.3 (new "Concepts" 
section on profiles, modules, levels), or in GL9 (extensibility).



Received on Monday, 28 April 2003 12:51:27 UTC