- From: Karl Dubost <karl@w3.org>
- Date: Mon, 3 May 2004 14:27:28 -0400
- To: www-qa-wg@w3.org
- Message-Id: <886C5BEB-9D2F-11D8-8734-000A95718F82@w3.org>
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 Monday, 3 May 2004 18:20:28 UTC