W3C home > Mailing lists > Public > public-html@w3.org > August 2007

[HDP] Missing principles

From: Richard Ishida <ishida@w3.org>
Date: Thu, 23 Aug 2007 16:19:21 +0100
To: "'public-html'" <public-html@w3.org>
Message-ID: <00d201c7e598$fb9f2890$6401a8c0@rishida>

These are comments I wanted to make while responding to http://www.w3.org/2002/09/wbs/40318/dprv/  They reflect my own personal views.

> 1. General Comments

I think a couple of useful principles are missing:

[1] Deliver incrementally (or similar words). 

I think we need a project plan that aims at releasing incremental versions of the specification over short intervals, rather than producing a huge behemoth of a specification in 10 to 12 years from now.  

We can perhaps start with a reasonably large initial publication, given our experience with HTML 4.0 issues, especially to reflect current realities, and perhaps include some immediately needed and well agreed upon features, but aim for something that's achievable within a year or two.  Then progress further in small steps based on prioritised user/author needs and agreement among implementers to advance together.  This, in a sense, means applying principle 2.5 (Evolution not Revolution) to the process of producing the specification as well as to design changes.

I think we need to plan this, not just see what we have achieved in two years time.

I also believe that frequent incremental releases should allow us to better address bug fixes to the spec as gaps and ambiguities are spotted through everyday use.

This approach facilitates the next missing principle...

[2] Collaborate with implementers (or similar words). 

For true interoperability, I think we need to work closely with at least a reasonably representative selection of implementers. We should seek commitment from implementers to incorporate a given set of features in a given period, and then tailor the specification work to standardise those features during that time period. Implementers should agree to move these features forward together.  For example, if we produce a huge set of new features and IE implements one third of them, Firefox implements a different third, and Opera the other third, we are no closer to interoperability.  Likewise if implementations vary in approach to a single feature, or if we have gaps in the spec or ambiguities that are handled in different ways by different UAs.  

This, of course, will require constant dialogue between implementers, users/authors and standards specifiers. Note that I'm not saying that implementers should call the shots, users and authors come ahead of them for determining what is needed, as we say in principle 3.2 Priority of Constituencies, but the spec shouldn't range too far in front of the implementations either.

We should develop implementations and tests in parallel with the later stages of spec work for a targeted release, and build back into the specs any gaps or ambiguities that arise from the implementation and testing work.

Implementers should also be involved later in improving the spec to eliminate gaps and ambiguities that arise during real world use after publication.

Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
Received on Thursday, 23 August 2007 15:17:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC