QA WG review of Webarch doc?

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