Re:PROPOSAL: Policy Statement on Evolution of Modules

Hello,

I'm a technical writer who is volunteering services to the working group.
Below is an edited version of the proposal (along with an attached version
in Word with track changes) for you to consider. I apologize if anything was
inappropriately changed. If so, please let me know.

Thank you,
Christina Bottomley


In general, XHTML specifications include implementations of their
requirements in various syntaxes (e.g., XML DTD, XML Schema, RelaxNG).
 These implementations are normative, and are meant to be used either 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 a normative part of the W3C Recommendation in which they are
presented, these implementations are also code containing potential errors
or omissions.  When such errors are discovered, it is sometimes important
that they be addressed very quickly to ensure that technologies relying on
the implementations work as expected (e.g., validators and content authoring
systems).  The W3C process allows for the publication and frequent updating
of errata, but unfortunately this process does not enable implementations to
be quickly updated.  As a result, the XHTML 2 Working Group has adopted the
following concerning the production and evolution of its implementations:


   - All implementations will 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.  These
   conventions require that the System Identifier must include a revision
   number.  This revision number is ONLY incremented when a revision is not
   backward compatible.
   - Each applicable Recommendation will include fixed, unchanging versions
   of those implementations within the formal dated location for the
   Recommendation (/TR/YYYY/REC-whatever-YYYYmmdd/...).
   - The Working Group will also provide a version of that implementation in
   the working group space (/MarkUp [5] [6]), uncoupled from a specific dated
   version of the associated Recommendation. In the beginning this uncoupled
   version will be *identical* to the version from the associated
   Recommendation.
   - If the Working Group identifies a problem with an implementation, and
   it is possible to solve the problem in a way that is 100 percent backward
   compatible, then the version in the group's space will be updated in place
   and an announcement will be sent to the XHTML 2 public email list.


The XHTML 2 Working Group states that the term "backward compatible" should
be used only when:


   - 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 the above constraints would be violated by a change, the
working group will either 1) not make the change, or 2) revise the
applicable module.  In the latter case,  the working group will also

________________________________

[UN1]"Syntaxes"

On Thu, Aug 7, 2008 at 9:06 AM, Roland Merrick <roland_merrick@uk.ibm.com>
wrote:
>
> Greetings Shane, this looks fine as far as it goes but it would be
worthwhile adding how any problem identified in point 4 relates to an
erratum and when and how these errata will be rolled up into a new edition
and eventually get updated in TR space.
>
> Regards, Roland
>
>
>
> From: Shane McCarron <shane@aptest.com>
> To: XHTML WG <public-xhtml2@w3.org>
> Date: 06/08/2008 16:34
> Subject: 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
>
>
>
>
>
>
>
>
> ________________________________
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>