W3C home > Mailing lists > Public > www-qa-wg@w3.org > May 2004

Re: Extension/Extensibility examples in W3C Specifications

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Tue, 04 May 2004 08:19:58 -0400
Message-Id: <5.1.0.14.2.20040504080850.01d43898@mailserver.nist.gov>
To: Karl Dubost <karl@w3.org>, www-qa-wg@w3.org
Cc: www-qa@w3.org

This is helpful. It basically says that, you can extend the specification 
by using the defined mechanism. In the case of XHTML, the mechanism takes 
the form of a set of conformance rules.

This is in contrast to Mark's view (which I finally understand) - His view 
is that, if you use the defined mechanism, then it isn't an 
extension.  Extensions are adding new features beyond what is defined in 
the specification, but not using any provided hooks or other mechanisms in 
the specification.  Thus, if a specification provides a "standard way to be 
non-standard" by including hooks in the specification or other mechanisms 
by which new functionality may be added in a conforming way - then what is 
added, is not an extension.

With Mark's definition, profiles, modules, levels are not considered 
extensions.
Also, note that we define profiles, modules, and levels as ways to 
sub-divide the specification - this implies no new features can be added to 
profiles, modules, levels --- since if you add something, it won't be a 
subset of the specification.

Any comments?

Lynne.









At 02:27 PM 5/3/2004, Karl Dubost wrote:
>Lynne & al.
>
>I went through a few specifications to find examples of "extension
>mechanisms".
>
>* XHTML Modularization [1]
>
>-> Modularization helps extensibility
>         """Modularization also allows for the extension of XHTML's
>         layout and presentation capabilities, using the extensibility
>         of XML, without breaking the XHTML standard. This development
>         path provides a stable, useful, and implementable framework
>         for content developers and publishers to manage the rapid
>         pace of technological change on the Web."""
>
>The mechanism for extensibility is basically defined by rules of
>conformance. XHTML Modularization defines the notion of a family. You
>belong to the family if you respect certain criterias which are defined
>in "3.3. XHTML Family Module Conformance " [3], you have in fact a
>
>-> 1st: You define the extension by using W3C Technonologies
>         => i.e. XML DTD or XML Schema. (exit RelaxNG it seems)
>-> 2nd: The extension is defined with a unique identifier.
>         => Here the naming rules are defined
>-> 3rd, 6th: The features are uniquely recognizable
>         => Here unique prefixes or a similar method
>         => Unique namespace for defined modules
>-> 4th: The features are clearly described and documented.
>         => Here syntactic and semantic requirements
>-> 5th: An extension never override things which are already defined.
>         => Though they seem to soften it a bit by authorizing similar 
> things
>if it has its own namespace, for example.
>
>So an extension is
>         an addition to the technology
>         which is uniquely identifiable
>         and do not redefine behaviour of the technology it extends
>         and can have some organization and naming constraints defined by 
> the
>technology it extends.
>
>They also give examples of DTD implementations
>
>And I have realized, that in [3], there's a normative section which is
>not written!!!
>
>[1] http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/
>[2]
>http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- 
>modularization.html#a_schema_developing
>[3]
>http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- 
>modularization.html#s_conform_module
>
>
>* Behavorial Extension to CSS [4]
>
>I don't know what will become of this document (The last working draft
>is from 1999 but it's interesting to read. The document proposes to
>use scripting feature driven by CSS selectors. It defines an extension
>on CSS, redifining or copying another W3C technology (DOM).
>
>For example, proposition of a
>         @script "text/javascript";
>instead of the traditional (X)HTML
>         <script type="text/javascript" />
>
>The benefits envision here is to make it reusable for any kind of XML
>documents, but in a sense it could be done with a:
>         <xhtml:script type="text/javascript" />
>
>
>The question illustrated is a technology by an extension mechanism can
>redefine another technology.
>         Can CSS redefines some behaviour of XHTML, DOM?
>         Can SOAP redefines some property of HTTP?
>         etc.
>
>[4] http://www.w3.org/TR/1999/WD-becss-19990804
>
>
>* CSS-3
>
>I can't find the document right now which defines CSS-3 extensibility,
>but basically the first draft which has been given to me was defining a
>very clear mechanism (scheme) to name the new selectors.
>
>         -vendor-name-features
>
>         + minus to start
>         + vendor identification
>         + name of the features
>
>But if I remember they were no requirements that the documentation
>explaining, describing the feature was published. Maybe there should be
>a clear policy about that too.
>         I see few minor caveats:
>         + vendor identification, name conflict: It will not happen often, 
> but
>it might happen.
>         + if we ask for a clear description of the created extension, where
>this documentation should be?
>         Usually we have the requirements to put in a clear and *stable* 
> place
>(Cool URIs don't break), though it's not often the case. Should we
>encourage people to send them to www-archive? or to have a kind of Web
>repository like www-archive.
>
>
>I will continue to try to find new examples.
>
>
>--
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager
>*** Be Strict To Be Cool ***
>
>
Received on Tuesday, 4 May 2004 08:21:37 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:15 GMT