- From: lynne rosenthal <lynne.rosenthal@Nist.gov>
- Date: Tue, 07 Sep 2004 14:23:42 -0400
- 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 UTC