W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2009

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

From: Jim Melton <jim.melton@oracle.com>
Date: Thu, 15 Oct 2009 11:26:24 -0600
Message-Id: <>
To: Ian Jacobs <ij@w3.org>
Cc: spec-prod@w3.org,chairs@w3.org,W3C Members <w3c-ac-members@w3.org>

I appreciate Robin's well-said message suggesting some questions 
whose answers should guide this topic as it goes forwards, and I'd 
like to take the opportunity to express my viewpoint on his 
questions.  (I hasten to add that my opinion does not represent any 
official position of my employer, but does represent my experience as 
a Working Group chair and as an editor of standards in several 
different fora for two and a half decades.

With respect, I don't believe that moving the discussion to spec-prod 
is necessary, and it might not be helpful.  I don't believe that any 
of my WG's editors are subscribers to spec-prod (indeed, I'm not 
certain that I myself am a member), much less all members of my 
WG.  This subject is of sufficient importance that I believe it 
deserves the widest visibility.

At 10/15/2009 08:32 AM, Robin Berjon wrote:

>   - Should this experimentation be performed on live Recommendations
>at their canonical URLs?

Absolutely not, and the W3C team should not have to be told 
this.  Commercial enterprises know never to make experimental changes 
to the products on which their customers depend, nor even to their 
production systems used internally only.  Arguments that "we didn't 
change the original documents, which were still available at their 
original URIs" don't really fly.  The "most recent version" URIs 
resolved to the reformatted documents, as did the reformatted TR 
page, and the vast majority of the general public use either the 
shortname URI (most recent version) or the TR page links to access 
W3C documents.  Virtually nobody manually types in a dated URI to 
access a specific version, and they can do that only if they happen 
to have memorized the date of publication in any case!

>   - Should old documents be updated at all? If yes, should the WGs in
>charge handle them?

I don't actually think that the reformatting is justified for old 
documents OR for new documents.  I disagree with some who have said 
that the new format looks better, but that's obviously nothing more 
than a matter of personal taste.  My reason for objecting to the 
reformatting is as simple as this: W3C has spent enormous resources 
developing a brand and recognition of its specs.  Changing the 
appearance of the brand for no apparent reason beyond changing it has 
proven to be a major problem for many commercial enterprises and it 
may do so for W3C as well.  There is value in being perceived as an 
organization that produces stable specifications and seemingly 
arbitrary changes (even to the formatting) might cause some of your 
customers to question that perception.

More importantly to me, and to my WG, is the fact that we've spent a 
tremendous amount of effort, time, and energy creating document 
features that make our documents easier to use and to read, while 
remaining absolutely faithful to the W3C published style guide and 
the W3C look and feel.  Applying blanket reformatting to our 
documents without any knowledge of how our documents function has 
caused a variety of breaking changes, including some functional 
breaks (admittedly, however, most are formatting breaks).  To adapt 
our various enhancements to another look and feel will cost 
additional resources.  As my WG, like almost all other WGs, have 
extremely limited resources (heck, we are having problems just 
getting our minimum requirements accomplished) in a very bad economy, 
we simply do not understand how we should be expected to start 
re-doing work we've already done just so somebody's idea of 
"prettier" can be applied to our documents.

I cannot say what my WG members will decide in the future, but I 
would not be surprised if they would argue never to adopt these 
arbitrary reformatting changes.

>   - Do TRs need to have the site navigation included or are they

TRs are not, IMHO, supposed to be integral parts of the warp and woof 
of a web site.  They are supposed to be documents whose value is 
based in part on the ability to link within themselves and to link to 
other related documents -- not all of which are even available on 
that web site (e.g., IETF RFCs).  W3C policies and copyright clearly 
allow people to keep their own copies of the TRs, within their 
companies and on their private computers.  However much we might all 
wish that the world is 100% connected 24x7, it simply ain't so.  If I 
can't get my work done in a timely fashion when my Internet 
connection is broken, even though I have all the documents I need on 
my laptop, simply because I can't get to the W3C site to fetch a 
bunch of icons and menus, I am going to be increasingly less than 
enthusiastic about using the W3C TRs.

>   - Is it okay to have the logos of commercial companies on TRs?

Absolutely not, unless the technology represented by the logos are 
integral to the technical content of the given TR.  In other words, I 
might not object to, e.g., a Firefox logo on an HTML TR if it linked 
to a clean demo of some esoteric HTML feature that Firefox has 
implemented particularly well.

I don't mind there being various commercial companies' logos on the 
W3C web site (e.g., Google for a search box, Twitter for 
microblogging, and the like) and think that is well within the 
authority of the team to determine.  But the TRs are supposed to 
belong to the community, not to the W3C alone, and I presume that the 
owner of one search engine might not be an enthusiastic supporter of 
the technology defined by a specification on which the logo of (only) 
a competing search engine appears.  Whether it's intended as 
advertising or not (obviously not, in this case), perceptions matter.

Trust me, if the DB2 (database system by IBM) logo appeared at the 
top of every W3C spec, Oracle would not be an enthusiastic member of 
W3C for very long.

>   - Should the SotD and paraphernalia be pushed to the end?

No, I think not.  In spite of some recent comments to the effect that 
"nobody reads the SotD and valuable information is overlooked when it 
appears there", my experience is different.  I personally read the 
SotD to be sure that the document I'm reading is the one I wanted to 
read, and may people to whom I talk about W3C TRs have implied or 
stated that they do the same.  When I have to wait for the entire 
document to download (sorry, but not everybody has a 10MB/sec link to 
the Internet) before I can even tell whether "this' is the correct 
version, I tend to get frustrated.

My personal recommendation is that all of the reformatted TRs be 
removed immediately and the "real" documents be given the same 
visibility and accessibility they had last week.  I do not believe 
that any documents currently under development, much less those for 
which RECs or other final stages have been achieved, should be 
reformatted without an explicit opt-in decision by the developing 
WG.  I would prefer that documents not yet under development by any 
arm of the W3C continue to use the current ("old") formatting, 
because I don't think it's helpful to change it, certainly not in the 
way that it has been experimentally changed.  However, if a rather 
more carefully thought out reformatting effort were to eventuate, 
then perhaps future documents could be created using the new 
formatting/style rules.

Hope this helps,

Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Chair, W3C XML Query WG; XQX (etc.) editor       Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
Received on Thursday, 15 October 2009 17:28:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:18 UTC