PROPOSAL: Policy Statement on Evolution of Modules

As per my action item, below is a draft policy statement concerning the 
evolution of Module implementations:

In general, XHTML specifications include implementations of their 
requirements in various grammars (e.g., XML DTD, XML Schema, RelaxNG).  
These implementations are normative, and are meant to be used as 
building blocks for new markup languages (e.g., XHTML Modularization 
[1]) or as complete markup language implementations (e.g., XHTML 1.1 
[2]).  While these implementations are a normative part of the W3C 
Recommendation in which they are presented, they are also /code/ that 
contains potential errors or omissions.  When such errors are 
discovered, it is sometimes important that they be addressed very 
quickly in order to ensure that technologies relying upon the 
implementations work as expected (e.g., validators, content authoring 
systems).  The W3C process allows for the publication and frequent 
updating of /errata/, but unfortunately that process does not lend 
itself to the quick updating of these implementations.  As a result, the 
XHTML 2 Working Group has adopted the following process and policy 
concerning the production and evolution of its implementations:

   1. All implementations adhere to the naming convention(s) and
      evolution rules as defined in XHTML Modularization [3] [4].  These
      names include both Formal Public Identifiers and System
      Identifiers.  Part of these conventions is that the System
      Identifier must include a revision number.  This revision number
      is ONLY incremented when there is a revision of the implementation
      that is not backward compatible.
   2. Each Recommendation that provides implementations will include
      fixed, unchanging versions of those implementations within the
      formal dated location for the Recommendation 
      (/TR/YYYY/REC-whatever-YYYYmmdd/...).
   3. The Working Group will /also/ provide a version of that
      implementation in working group space (/MarkUp [5] [6]), uncoupled
      from a specific dated version of the associated Recommendation.
      This version will start out being *identical* to the version from
      the associated Recommendation.
   4. If the working group identifies a problem with an implementation,
      and it is possible to solve the problem in a way that is 100%
      backward compatible, then the version in the working group space
      will be updated in place and an announcement about the update sent
      to the XHTML 2 public email list.

For the avoidance of doubt, the XHTML 2 Working Group defines "backward 
compatible" as:

    * The external interface to the module cannot change in any way that
      would break another module or markup language, either within or
      outside of the W3C.
    * The content model cannot change in any way that would cause a
      previously valid document to become invalid.

If either of these constraints would be violated by a change, the 
working group will either 1) not make the change, or 2) create a new 
revision of the module in which the incompatible change is made.  In the 
latter case,  the working group will also

[1] http://www.w3.org/TR/xhtml-modularization
[2] http://www.w3.org/TR/xhtml11
[3] 
http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_naming_rules
[4] 
http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_commitment
[5] http://www.w3.org/MarkUp/DTD
[6] http://www.w3.org/MarkUp/SCHEMA

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Wednesday, 6 August 2008 15:33:23 UTC