Re: QA WG review of Webarch doc?

Although I cannot attend the Monday telecon, and I don't have time for 
detailed comments now (more later, before Reading...), I'll make a couple 
of general comments.

In general, I think that WebArch has a too lenient position about 
Extensibility.  Compare that to what SpecGL said in its early WDs, LC 
versions, and even CR.  SpecGL's initial approach was:  extensibility is 
often (usually?) pernicious, is often carelessly used, can have and often 
does have serious negative interoperability effects that outweigh the 
benefits, and therefore should be carefully justified and rigorously 
constructed.

I think that SpecLite has drifted a bit too far away from that cautionary 
approach (more comments later), and WebArch is too far from that 
approach.  As I interpret, Karl is saying similar in his comments...

At 02:11 PM 9/7/2004 +0200, Dominique Hazaël-Massieux wrote:
>[...]
>I have had a look at the 2nd LC of WebArch [1] as per my action item
>from our last meeting; while there are a few topics in common between
>WebArch and SpecGL (mainly extensibility and error handling), I haven't
>found anything specific that needs to be addressed, since I think the
>TAG is now mostly on the same line as we are.
>
>Karl's personal review [2] of the document seems to indicate a different
>point of view, esp. on the extensibility topics, so I think we'll need
>to discuss this next week.

I agree with Karl's comments in KD-013.

(Several more small comments embedded below...)


>Otherwise, I would limit our LC comment to:
>* the acknowledgment that we have these topics in common, and that the
>TAG should coordinate with us before making substantial changes to these
>sections; we could also maybe suggest a repartition of role on these
>topics to avoid the duplication of efforts.

A joint telecon has been suggested.  QA should consider that.

>* the need to get our definitions of extensions/extensibility in sync;
>"Extensibility describes the property of a technology that promotes both
>evolution and interoperability" doesn't seem very appropriate as a
>definition
>
>FWIW, here are the relevant pointers:
>
>* Extensibility:
>- """4.2.  Extensibility
>Good practice: Extensibility mechanisms
>A specification SHOULD provide mechanisms that allow any party to create
>extensions that do not interfere with conformance to the original
>specification
>[...]
>Good practice: Unknown extensions
>A specification SHOULD specify agent behavior in the face of
>unrecognized extensions.
>[...]
>Extensibility is not free. Providing hooks for extensibility is one of
>many requirements to be factored into the costs of language design.
>Experience suggests that the long term benefits of extensibility
>generally outweigh the costs.
>"""
>http://www.w3.org/TR/2004/WD-webarch-20040816/#extensibility
>
>"""

This claim -- "experience suggests" -- is completely unsubstantiated.   It 
sounds like "boosterism".  (Promoting extensibility as great stuff.)

In fact, I don't think I believe it as a generalization.  (My own direct 
experience with extensibility leads me to the opposite conclusion, but then 
again my direct experience with W3C standards is limited to a few.)

The statement should be dropped or documented.  I.e., if it is going to be 
kept, then TAG (or QA?) should do a survey of W3C standards (and others), 
and document the cases where benefits outweigh costs, cases where costs 
outweigh benefits, etc.

>Extensibility
>Extensibility describes the property of a technology that promotes both
>evolution and interoperability [...]
>
>Extended language: If one language is a subset of another, the latter
>superset is called an extended language; the difference between the
>languages is called the extension. Clearly, extending a language is
>better for interoperability than creating an incompatible language.
>
>[...]
>Experience shows that designs that strike the right balance between
>allowing change and preserving interoperability are more likely to
>thrive and are less likely to disrupt the Web community.
>"""
>http://www.w3.org/TR/2004/WD-webarch-20040816/#language-extensibility

This claim -- "experience shows" -- is completely documented.  What 
experience?  How about showing some examples that have struck the right 
balance, and some that haven't?

All for now,
-Lofton.


>- Error handling
>"""
>5.3. Error Handling
>To promote interoperability, specification designers should identify
>predictable error conditions. Experience has led to the following
>observations about error-handling approaches.[...]
>"""
>http://www.w3.org/TR/2004/WD-webarch-20040816/#error-handling
>
>Dom
>
>1. http://www.w3.org/TR/2004/WD-webarch-20040816/
>2.
>http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0048.html
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/ERCIM
>mailto:dom@w3.org

Received on Sunday, 12 September 2004 16:13:17 UTC