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

Re: Some thoughts on a new publication approach

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Sun, 27 Oct 2013 14:06:43 +0900
Message-ID: <526C9F63.2080300@it.aoyama.ac.jp>
To: Karl Dubost <karl@la-grange.net>
CC: Robin Berjon <robin@w3.org>, "spec-prod@w3.org" <spec-prod@w3.org>
On 2013/10/22 7:48, Karl Dubost wrote:
> Not really publication, but more post-publication, managing the future past.
> Le 21 oct. 2013 à 10:26, Robin Berjon a écrit :
>> Every draft in TR is required to feature a pointer to its existing snapshots (how many there are will depend on how advanced it is).
> Very often people complained about the facts that implementers were having access to old versions of a specification. Something else that could be done.
> Linkable doesn't mean indexable.
> So when version N is published, it could be possible to add version N-1 in robots.txt. such as

I'd personally strongly be against that approach. Even if it's only for 
historical reasons, I want to be able to e.g. find the draft that 
included a once-considered but not adopted feature. I don't think we 
should do the search engines' work.

It may also be that for whatever reason, some snapshot is more popular. 
It may be that there's a spec that's more interesting to lawyers than to 
implementers, or that a particular version of a spec contains something 
that can be read as a funny joke, or whatever.

Even more, this proposal, as far as I understand it, would essentially 
make it impossible to go search for "foo-tech Last Call". That would be 
bad. I'm not exactly sure how to express this, but in some way, tweaking 
robots.txt for this feels like censorship to me.

I also don't think we should treat implementers are children (with 
respect to them not being able to find the right version). But we may 
need to seriously consider what kind of labeling and 
communication/outreach efforts we need, Not everybody in the wider 
implementation community (not only browser vendors, but wide range 
including web agencies,...) is already completely familiar with the 
concept of a "living spec".

I'd also like to have a clearly thought out strategy with respect to 
distinguishing truely dead (i.e. abandoned) specs, and specs that aren't 
updated every month or year because there are no bugs found.

Regards,   Martin.
Received on Monday, 28 October 2013 01:28:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 28 October 2013 01:28:03 UTC