Re: Extension/Extensibility examples in W3C Specifications:

This is helpful.


>An additional reason (point 2.) might read
>
>- some technologies are explicitly intended as a foundation for 
>extensions, e.g. XML, RDF and XHTML
>
>[At least some member of RDF Core, probably all those who were also 
>members of WebOnt, see the value of RDF being realised in OWL.]

Nicely said.

>Another issue which might be worth a short piece of text is if you are 
>building an extension, you should consider what happens when you intereact 
>with other extensions. Can extensions be combined? I don't think WebOnt 
>explored this, and it may have impacted our design decisions if we had.
>I guess that too could be a further bullet point under 2.
>e.g.
>
>- your specification is itself an extension of some other spec. Maybe the 
>extensibility mechanism you are using, can continue to be used to extend 
>the extension.

This is a point that David Marston always points out - interactions with 
other dimensions of variability.  I agree, that something should be said, 
as a caution to editors/writers and something they need to think about.

Thanks again for your helpful comments.
Lynne


>Lynne Rosenthal wrote:
>
>>The following is my attempt at summarizing a very interesting and 
>>informative discussion on extensions/extensibility and organize it in 
>>some way, so that we can incorporate it in the rewrite of the 
>>Specification Guidelines (SpecLite).   Please let me know where I've 
>>misrepresented something or just got it wrong as well as helping to add 
>>more detail and examples.   Additionally, I've indicated questions using @@.
>>1.  Definitions:  There is no clear definition of extension or 
>>extensibility, although both terms are used and seem to be understood 
>>within the context of their use.  They are tied closely to their (base) 
>>specification and vary as to the specificity of their meaning, use, 
>>invocation, etc.  However, there are characteristics that apply and a 
>>general definition can be derived.
>>Extension: characteristics that seem to always be true
>>  - additional feature (@@functionality?) to the specification.
>>  - does not break/negate the base specification
>>@@Are the following always true?
>>  - does not redefine existing technology (counterexample: CSS- By 
>> providing alternatives to another technology (@@is this true?)
>>- non-standardized functionality or capability beyond the scope of the 
>>specification. (counterexample: ??)
>>Therefore, general definitions:
>>a) Extension is the incorporation of additional features, beyond what is 
>>defined in the specification.
>>b) Extensibility is the ability of a specification to accept extensions 
>>in a defined way.  A specification is extensible if it provides a 
>>mechanism for any party to create extensions that do not interfere with 
>>conformance to the specification.
>>2.  Reasons for designing extensibility into a specification
>>- there will be extensions, it is inevitable.
>>- to accommodate the changing technology and information on the Web
>>- provides a stable, useful, framework to manage the rapid pace of 
>>technology change
>>- 'test drive' new functionality that may migrate into future specifications
>>- provides a consistent manner, leading to predictable handling of extensions
>>- less change for extension to interfere with conformance to the 
>>specification and a better change for achieving interoperability.
>>3.  Planning for extensibility
>>- depends on the specification and the technology.
>>- can be included as a provision or feature in the specification 
>>(example: XSLT, WSDL, others?)
>>- can be based on other specifications (example: CC/PP based on HTTP Ext. 
>>Framework, Owl's semantic extensions of RDF)
>>- can be a specification only about extensibility of the technology 
>>(example: Component Extension (CX) API, HTTP Extension Framework, XHTML 
>>Modularization?)
>>4. What is being extended
>>- the technology defined by the specification (example: XSLT, WSDL, others?)
>>- another technologies (RDF+OWL where OWL adds additional constraints, 
>>others?)
>>@@Where does XHTML Modularization fit? Where does CSS-3 fit?
>>5.  Different mechanisms.
>>Again technology and application dictates the best strategy and mechanism.
>>- mechanisms take different forms:
>>   -- conformance criteria/rules (XHTML),
>>   -- framework (HTTP ext framework, XHTML Mod),
>>   -- techniques (XSLT, WSDL)
>>@@ is this helpful?  is it correct?  Are there other mechanisms?
>>6.  Additional items
>>- error handling  how to handle unknown extensions (@@ does this apply to 
>>everything or just agents? )
>>- unique identifiers and declarations indicate extensions (HTTP ext 
>>framework, CC/PP) (@@ are there are examples of this?)
>>Thank you to all who have shared their knowledge, examples, and comments. 
>>I welcome all and any additional comments, examples, draft text, etc.
>>--Lynne
>
>

Received on Thursday, 6 May 2004 18:58:30 UTC