Subject: Work Queue Rotation #11

From: Tim Bray <[email-masked]>
Date: Mon, 18 Oct 2004 12:38:48 -0700

These are my takes based on watch the list and talking to Paul & Sam, 
occasional errors are inevitable and need to be pointed out.  Public 
issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

PaceDateOfSubject: This has 8 listed supporters.  There were two -1's 
in the WG, Hoehrmann 
(http://imc.org/atom-syntax/mail-archive/msg10355.html) on the grounds 
that it's not sufficiently generic, and Roundy 
(http://imc.org/atom-syntax/mail-archive/msg10405.html) on the basis 
that this should be left to an extension.  However, note that neither 
are opposed to the concept.  I think this almost but not quite 
qualifies as "rough" consensus, so back on the revisit queue with it.  
Those who want this need either to buy into an extension framework or 
convince the opposition.

PaceLinkTitle: It certainly didn't get consensus this time around, 
strong -1 from Sayre 
(http://imc.org/atom-syntax/mail-archive/msg10410.html) and requests 
for changes from Roundy 
(http://imc.org/atom-syntax/mail-archive/msg10403.html).  Let's put it 
back in Revisit, if someone wants to redraft it to address the concerns 
go ahead, if it fails to pass next time around it's dead.

PaceMoveLinkElement: [Hey, he's cheating!  That's not on to-discuss!]  
Um, even though this wasn't on our list, it got proposed and got some 
favorable comment and no -1's, and if we adopted it, this would make 
our editors' lives easier.  It's even arguable that's in the domain of 
editorial judgement, not policy.  So let's mark this accepted and do 
that spec-to-spec transplant.

PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, 
PaceLinkParent, PaceLinkPurpose, PaceLinkRelMechanism, 
PaceReplaceLinkElement

As I pointed out earlier 
(http://imc.org/atom-syntax/mail-archive/msg10570.html), we lack 
consensus on multiple axes.

However, having revisited the discussion and talked with Paul/Sam, I'm 
going to reverse my position on PaceLinkAttrDefaults.  While it got 
some -1's (http://imc.org/atom-syntax/mail-archive/msg10432.html, 
http://imc.org/atom-syntax/mail-archive/msg10400.html, 
http://imc.org/atom-syntax/mail-archive/msg10382.html), they were 
mostly "This goes too far".  Which may be correct, but where it goes is 
precisely to the minimum point of consensus.  I believe we *do* have 
good-enough consensus that there should be a <link rel="alternate"> and 
also on rel="related".  We do *not* have consensus as to what, if any, 
other values should be allowed, and we do *not* have consensus on what 
extension mechanism, if any, should be provided for the value space.  
But, <important>we also do not have consensus support for the values 
currently listed in the draft</important>.  So, I'm going to call for 
PaceLinkAttrDefaults to be accepted; rolling this into the spec will in 
fact reflect the minimum shared understanding better than what's there 
now.

As for all the other Paces, PaceLinkRelMechanism is closed and the rest 
go back on the Revisit queue.  Following that, I'm going to launch a 
general discussion on link extensibility, whether and how, to see if we 
can get consensus on basics, which should allow us to discard most of 
these Paces and build something people can buy into.  -Tim