Alistair, thank you very much for the detailed comments. I will spend some time updating and revitalizing the draft today. Once I post the updated version, we can pick up the discussion from there.
On Thu, Nov 4, 2010 at 6:43 AM, Alistair Miles <[email protected]>wrote: > Hi James, > > On Tue, Nov 02, 2010 at 03:47:58PM -0700, James Snell wrote: > > Ok, I was just looking over the old revision draft. I can definitely see > a > > number of key changes that can be made... > > > > 1. Drop the deleted-entry element in favor of the Atom Tombstones Draft > > +1 > > > 2. Drop all of the link-relations in favor of those defined in RFC5829 > > I think this might need a bit of discussion. > > Two possible issues here... > > One simple issue, the mapping from link relations defined in your revision > tracking I-D to RFC5829 is incomplete... > > history -> version-history > diff -> ??? > initial-revision -> ??? > current-revision -> latest-version > this-revision -> ??? > prior-revision -> predecessor-version > next-revision -> successor-version > > We haven't actually implemented the diff relation, but we make heavy use of > "this-revision" - it's how a client navigates from a history feed (which > might contain an incomplete representation of each revision for efficiency > reasons) to a full representation of a specific revision. > > Another possible issue is that RFC5829 anticipates source-code style > versioning, > defining notions of "working copy" and "checkout". We don't have any need > for > these notions, and it might be easier to get consensus on a new atom > revision > tracking draft if we kept it simple and limited it to consider only > provision > of revision history where versioning is transparent to the client. > > > 3. Refine the definition of ar:revision to: > > > > revision = element ar:revision { > > atomCommonAttributes, > > attribute label { text }, > > attribute scheme { atomIRI }?, > > (atomAuthor?, > > atomUpdated?, > > atomSummary?, > > undefinedContent) > > } > > > > This gives us the simplest example: > > > > <ar:revision label="01" scheme="http://example.org/foo"; /> > > > > If we want to indicate who made the revision, when, and provide a > > revision comment, we would do: > > > > <ar:revision label="01" scheme="http://example.org/foo";> > > <author><name>James</name></author> > > <updated>2010-12-12T12:12:12Z</updated> > > <summary>Removed some stuff</summary> > > </ar:revision> > > +1 to add atomAuthor here > > Also I suggest making it clear that the atom:summary element within > ar:revision > is *the* place to put *the* revision comment for a specific revision. > > Are you proposing to drop the @number attribute? What about @initial, > @final, @significant? I could live without @significant (not sure how this > is determined anyway) but @initial and @final are useful. > > > 4. I'd like to drop the ar: namespace and define the revision, comment > and > > host elements within the Atom namespace. > > > > e.g.: > > <entry> > > ... > > <revision label="01" scheme="http://example.org/foo"; /> > > ... > > </entry> > > > > Thoughts? > > Doesn't matter to me either way. > > I think also the intended/expected usage of the ar:comment element needs a > bit of discussion too. > > Thanks, > > Alistair > > > > > On Tue, Nov 2, 2010 at 2:24 PM, Julian Reschke <[email protected] > >wrote: > > > > > > > > On 02.11.2010 19:18, Erik Wilde wrote: > > > > > >> > > >> hello alistair. > > >> > > >> On 2010-11-02 4:11, Alistair Miles wrote: > > >> > > >>> This is just a short note to say that we've done an implementation of > > >>> James > > >>> Snell's 2006 I-D on a revision tracking extension [1], see the > > >>> documentation > > >>> at [2]. > > >>> [1] http://tools.ietf.org/html/draft-snell-atompub-revision-00 > > >>> [2] http://code.google.com/p/atombeat/wiki/TutorialVersioning > > >>> > > >> > > >> http://tools.ietf.org/id/draft-brown-versioning-link-relations-07.txtis > > >> something that is more recent and seems to cover similar use cases, > even > > >> though it's using only link relations instead of a mix of elements and > > >> link relations. the latest version of that is also expired (but not > > >> nearly as old as draft-snell-atompub-revision), but now that RFC 5988 > is > > >> published, maybe a new version will be published soon? > > >> > > > > > > It has been published as RFC; why are you expecting a new version? > > > > > > > > -- > Alistair Miles > Head of Epidemiological Informatics > Centre for Genomics and Global Health <http://cggh.org> > The Wellcome Trust Centre for Human Genetics > Roosevelt Drive > Oxford > OX3 7BN > United Kingdom > Web: http://purl.org/net/aliman > Email: [email protected] > Tel: +44 (0)1865 287669 >
