Re: [draft] Comments from the QA WG on WebArch 2nd LC (extensibility)

Excellent.  This captured the discussion.

-lynne


>I plan to send these comment Friday morning; please send any
>corrections/suggestions that you would have by then.
>
>-----
>Hello,
>
>Here is the QA Working Group's review of
>"""
>Architecture of the World Wide Web, First Edition
>W3C Working Draft 16 August 2004
>http://www.w3.org/TR/2004/WD-webarch-20040816/
>"""
>
>The Working Group noted that WebArch has 2 main intersections with the
>QA WG own documents, concerning error handling and extensibility. Indeed
>the QA WG addresses this topic, esp. in its "Specification Guidelines":
>http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
>http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#error
>which matches with WebArch own sections at:
>http://www.w3.org/TR/2004/WD-webarch-20040816/#extensibility
>http://www.w3.org/TR/2004/WD-webarch-20040816/#error-handling
>
>While our views on error handling seems to be in sync, the WG noted the
>following issues with regard to the extensibility topics:
>
>* Extensibility is defined as follow in section 5.2:
>"Extensibility describes the property of a technology that promotes both
>evolution and interoperability"
>This may be what well-used extensibility is good for, but that doesn't
>seem like an objective description of what extensibility is.
>SpecGL says that "a specification is extensible when it provides a
>mechanism to allow any party to create extensions", where extensions are
>"incorporate additional features beyond what is defined in the
>specification".
>
>* the QA WG would like to see the current wording of the first good
>practice on extensibility (section 4.2.3) changed; it reads
>"A specification SHOULD provide mechanisms that allow any party to
>create extensions that do not interfere with conformance to the original
>specification."
>The QA WG firmly believes that in no occasion an extension should be
>allowed to interfere with conformance to the original spec; while it may
>redefine semantics on top of the original semantics, interfering with
>the conformance of the original spec would break the extensibility
>mechanism itself.
>The current wording makes it unclear whether the SHOULD is about
>"allow[ing] any party to create extensions" or the property of
>extensions not "interfer[ing] with conformance to the original
>specification."
>Ideally, WebArch would MUST-NOT the interferences with conformance.
>
>* section 4.3.2 reads "Experience suggests that the long term benefits
>of extensibility generally outweigh the costs"; since several QA WG
>participants have had a contrary experiences, the QA WG would be
>interested to know about specific examples of this experience.
>The QA WG would rather see this either removed, or softened (à la "the
>long term benefits of a well-designed extensibility mechansim..."), but
>at the very least explained.
>
>* the QA WG would like to suggest to link to the relevant parts of
>SpecGL on both the extensibility and error handling topics, so that the
>reader can get a different point of view on this with a different focus.
>
>* more generally, the QA WG would like to work in coordination with the
>TAG on this topic, as was suggested earlier:
>http://lists.w3.org/Archives/Public/www-qa-wg/2004Aug/0137.html
>
>Regards,
>
>Dom
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/ERCIM
>mailto:dom@w3.org
>

Received on Monday, 13 September 2004 17:11:06 UTC