W3C home > Mailing lists > Public > spec-prod@w3.org > July to September 2013

Re: Editor's drafts on /TR/… ftw, was Re: new TR tools and editor's drafts?

From: Marcos Caceres <w3c@marcosc.com>
Date: Tue, 2 Jul 2013 17:00:11 +0100
To: Frederick.Hirsch@nokia.com
Cc: plh@w3.org, spec-prod@w3.org, dsr@w3.org
Message-ID: <CB8DFE6975E84BF69F364DA5E80D2C99@marcosc.com>

On Tuesday, 2 July 2013 at 14:24, Frederick.Hirsch@nokia.com wrote:

> Are we are conflating discovery with "living specs"?
> Editors drafts should be allowed to be broken, etc as they are just that, editor drafts and should be separate from "approved" "authoritative" material - there is value in being able to reference approved material.
I think groups + editors should be given a choice here. As I've argued and shown (to death), "authoritative" drafts are often way more broken than Editor's drafts.  

Hence, if groups want to keep low priority, broken things, they can do so (and call them Editor's drafts). But other groups should be able to list things as "Living Standards" that are "authoritative" - it would be nice to have a W3C sanctioned style sheet and pub-rules recognized status for this.  
> Thus there is no logical reason to put them in TR other than to have a single repository.  

I agree for discardable things. But for something labelled a Living Standard, it should get the "authoritative" respect it deserves. But again, it should be up to the WG. That way, Editor's drafts can remain if people want them - and having something labelled Living Standard signals that there is no Editor's drafts.   
> Given the use of links I'm not sure that consistency of storage location is a major requirement.
> Currently TR drafts have links to the editors draft.
Yes, and this is very frustrating for us that never want to read the outdated stuff on TR.     
> I'm probably missing something in this discussion, but it seems like the "living spec" discussion again.

Funny how it keeps coming up, huh?  

As I've said, the best way to handle this is to give groups a choice. There is really no need for us to butt heads around this - we should just allow different work modes. When the W3C does not allow different work modes, then Editor's route around it (and publish stuff on a different license - the most liberal license of all - C0):


(That's like the core of the Web Platform! It completely undermines the whole trying to come up with a new W3C license effort AND the whole /TR/ is authoritative thing)   

And so on… there is a bunch more of those specs working around the W3C's limitation. I've been personally resisting moving my specs to the WHATWG (because I strongly believe there is a solution and know we can solve this … I just don't understand why it's taking so long to solve it :( ).   
Received on Tuesday, 2 July 2013 16:08:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:18 UTC