Comments from the QA WG on WebArch 2nd LC (extensibility)

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 the data (cases 
and examples) and method by which this conclusion was reached.
The QA WG would rather see this either removed, or softened (à la "the
long term benefits of a well-designed extensibility mechanism..."), 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