W3C home > Mailing lists > Public > public-webarch-comments@w3.org > July to September 2004

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

From: Stuart Williams <skw@hp.com>
Date: Wed, 22 Sep 2004 14:32:58 +0100
Message-ID: <41517F0A.6070202@hp.com>
To: Dominique HazaŽl-Massieux <dom@w3.org>
Cc: public-webarch-comments@w3.org, www-qa-wg@w3.org, dorchard@bea.com

Dominique, Karl, QA-WG,

The TAG would like to invite you to participate in our teleconference on 
Monday 27th September to discuss your comments on Webarch. We recognise 
that we have a larger thread of work in progress on the theme of 
Extensibility and Versioning [1,2], I am also inviting David Orchard to 
the call since he and Norm have been the prime movers in our work on 
that topic. However, to be clear, our (the TAG's) priority for 
discussion on the call is to address comments/changes that directly 
affect the Webarch document itself.

Further work on Extensibility and Versioning is on going and we should 
touch on how the QA-WG can work with the TAG and other stakeholders, but 
that should not dominate the call on Monday.

We were also wondering whether there was additional material in the 
current draft finding [2] that, inf included in the Webarch doc, would 
address any of your comments.

Wrt to meeting logistics, We meet on Mondays at 3pm Eastern Time. We use 
the W3C conference bridge at +1 617 761 6200 conference code 0824# 
(0TAG#). I'll be publish an agenda for the meeting tomorrow. I'm going 
to give 30-45min to this discussion, aiming to start at 3:15pm. That 
will leave the TAG with 15min for administriva at the beginning and 
30min for other business at the end. How does that sound to you?

David: can you confirm your availability too please?

Best regards


Dominique HazaŽl-Massieux wrote:

>Here is the QA Working Group's review of 
>Architecture of the World Wide Web, First Edition
>W3C Working Draft 16 August 2004
>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":
>which matches with WebArch own sections at:
>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
>* 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
>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
>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:
Received on Wednesday, 22 September 2004 13:33:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:47 UTC