W3C home > Mailing lists > Public > www-qa-wg@w3.org > September 2004

Re: QA WG review of Webarch doc?

From: lynne rosenthal <lynne.rosenthal@Nist.gov>
Date: Tue, 07 Sep 2004 14:23:42 -0400
Message-Id: <5.1.0.14.2.20040907142223.00b80308@mailserver.nist.gov>
To: Dominique HazaŽl-Massieux <dom@w3.org>, www-qa-wg@w3.org

just to let you know, when I originally drafted the extensibility section, 
I looked at the previous WebArch document and tried to be consistent.

-lynne


At 09:11 AM 9/7/2004, Dominique HazaŽl-Massieux wrote:
>Hi all,
>
>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.
>
>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.
>* 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
>
>"""
>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
>
>- 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 Tuesday, 7 September 2004 18:21:51 GMT

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