Abdera (was: Re: Consensus calls)

[James M Snell <jasnell@xxxxxxxxx>]

FYI,

So that folks can get started writing code in advanced of the -10 draft,
I've updated the Apache Abdera trunk [1] to reflect this round of
accepted paces.  The update includes support for app:categories and
app:modified elements (PaceAppCategories and PaceAppModified2), the Slug
header (PaceSlugHeader4), and using the same namespace for the control
element and service docs (PaceOneAppNamespaceOnly).

- James

[1] http://incubator.apache.org/abdera

Tim Bray wrote:
> 
> For each of the things on AtomPubIssuesList, we went through all the
> email we could find, dating back to the arrival of protocol-09.  We also
> make the call on a few other Paces that didn't make it into
> AtomPubIssuesList, because the WG leaning seemed clear enough.  The WG
> has created a number of new Paces since the last issues-list revision;
> we are not 100% sure at this time how to handle them, but this consensus
> call is a necessary first step.
> 
> There were a *lot* of messages here, so as always, it's possible that we
> misread the consensus.  Also, some may want to suggest that one or more
> of the Paces not covered here have obviously achieved or failed to
> achieve consensus and can be called now.  If so, please speak up (using
> an as-specific-as-possible subject line).
> 
> PaceAppCategories:  This is the hardest to call.  There are a ton of
> positive and neutral comments, but three -1's. We admit to prejudice in
> that the +1's and +0's include a lot of our implementors.  We think that
> one of the three -1's, from Andreas Sewe, could be turned around if the
> bug he reported in
> http://www.imc.org/atom-protocol/mail-archive/msg05780.html could either
> be fixed, or Andreas convinced that it's not really a bug.  Finally, we
> didn't see any of the opponents arguing that this would be damaging, but
> this Paces's supporters are pretty excited about it, think its lack will
> be a big hole in APP.  So...
> 
>   ACCEPTED.  The WG is asked to comment on Andreas' bug report and
> either refute it or suggest fixes.
> 
> PaceAppModified: REJECTED.  One +1, many -1's
> 
> PaceAppModified2: ACCEPTED.  Lots of support, only one objection.
> 
> PaceAppUpdated: REJECTED. Some friendliness, but only one +1; a few
> neutrals and a lot of -1's.
> 
> PaceCategoryLink: REJECTED.  Not a single +1, some neutral, lots of
> negatives.
> 
> PaceExtendIntrospection: ACCEPTED. One -1, but many many supporters
> (more than any other Pace I think).
> 
> PaceNoChangeID: REJECTED.  Unusually, significant numbers of both +1 and
> -1, but the Nays have it by quite a bit.
> 
> PaceOneAppNamespaceOnly: ACCEPTED. Up there with ExtendIntrospection for
> having mobs of supporters.
> 
> PaceRemoveTitleHeader2: ACCEPTED.  Another popular Pace, one lonely -1.
> 
> PaceRequireContentType: This is another tough call.  The breakdown of
> opinion is a bit like PaceAppCategories, but the balance in favor of
> supporters is much weaker.  Also, the supporters aren't arguing that
> leaving this out will leave a critical hole in APP.  So...
> 
>    REJECTED.  But not by much.
> 
> PaceSlugHeader4: ACCEPTED.  Two -1's, but a lot of support and nobody's
> saying doing it will be a calamity.
> 
> PaceTitleSafety: REJECTED.  Lots of support, but most of it was as a
> fallback if PaceRemoveTitleHeader2 failed.
> 
> PaceUnifiedEntryEditing: REJECTED. Crushed like a bug by waves of -1's
> 
> PaceRemoveMustOrderCollectionsByUpdated: REJECTED. Thank goodness we
> don't do things by voting, because this would have been a tie.
> 
> PaceUseElementsForAppCollectionTitles: Another tough one.  Discussion
> was intense, and very late in the day
> PaceUseElementsForAppCollectionTitles2 arrived, and got some +1's.  So...
> 
>    REJECTED, but... have a look at ...Titles2.  Would this remove the
> objections of Snell, Story, and Marvin without losing any supporters of
> the original?  Wouldn't take much.
> 
> PaceOrderCollectionsByAppModified: REJECTED. One for, one against, not
> good enough.
> 
> PaceOrderCollectionsBodyToPostRequests: REJECTED.  One for, one against,
> not good enough.
> 
> PaceURINomenclature: REJECTED, and
> PaceOnlyMemberURIs: ACCEPTED. Based in particular on discussion among
> the implementors who have their hands real dirty with this stuff.
> 
> PaceNoServiceDocument: REJECTED: Sorry; there screen-full after
> screen-full of messages, and eventually it became apparent that yes, you
> *could* probably get along without a specialized Service doc, but the
> idea of removing it doesn't have anything like rough-consensus support.
> 
> PaceSecurityConsiderations, PaceAuthenticationAndSecurity: There are
> enough positives and negatives on both that they will remain in play. 
> The chair has asked the two authors to make any changes they want by
> this Friday Sep 1st and the chairs will start a separate thread at that
> time.
> 
> 
> 
> 
> 
>