Re: Atom revision tracking extension

[James Snell <[e-mail]>]

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
2. Drop all of the link-relations in favor of those defined in RFC5829
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>


  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?

On Tue, Nov 2, 2010 at 2:24 PM, Julian Reschke <[e-mail]>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.txt is
>> 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?
>
>