Subject: Re: Propose partial consensus on dates

From: "Arve Bersvendsen" <[email-masked]>
Date: Fri, 23 Jul 2004 15:26:39 +0200

* Janne Jalkanen
> A wiki would probably change the <modified> -date each time someone made 
> an edit, but the <updated> -date only if it was not marked as a "minor 
> edit", which is a very common wiki functionality.

This model gives a way to distinguish between minor and major updates, but I
am afraid an 'updated' alone cannot solve the revisioning problem for
anything but non-revisioning aggregators. 

I would like to hear people's ideas/suggestions on how to make Atom handle
all of the following:

How can a revisioning mechanism be built into Atom that allows:
- For tools to import and export entries, including their entire editing
history.
- Non-revisioning tools to ignore the revision history, and still avoid
duplicates in their history (read: how can we ensure that these
non-revisioning tools will treat a "major revision" the same way it would
treat a "minor revision".
- Organizations/tools/people to support the use case that an entry may only
be issued exactly once, with an immutable 'issued' date.

-- 
Arve Bersvendsen

---

From: Robert Sayre <[email-masked]>
Date: Fri, 23 Jul 2004 11:14:26 -0400

> - For tools to import and export entries, including their entire editing

Extension content elements. Version control is not in the charter.

> treat a "minor revision".

They will. Just send them the same atom:id

> be issued exactly once, with an immutable 'issued' date.

Make sure there isn't a one-to-one ratio between resources and entries. Tag
your atom:ids with an accumulator. You can do this today.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sat, 24 Jul 2004 01:42:29 +1000

>> - For tools to import and export entries, including their entire editing

see and action this element in the entry...
    <link rel="history" type="application/atom+xml" href="..." />

>> treat a "minor revision".

ignore this element in the entry ...
    <link rel="history" type="application/atom+xml" href="..." />

e.

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 12:49:30 -0400

> be issued exactly once, with an immutable 'issued' date.

I think that there is more than simply "major" and "minor".

There is "typo", there is "update", and there is "revised".

There are people out there who obsessively update their entries through 
the course of the day.

There are people who occasionally issue Updates, often several days 
after the original item was posted.

And then there is the formal model where XML 1.1 is issued based on XML 
1.0, but both have separate URIs and identities.

As I see it, being able to capture the relationship between XML 1.1 and 
XML 1.0 is desirable.  Also desirable is for non-revisioning aggregators 
to recognize these links.

  - - -

Brainstorming: can't all of these be done using the dcterms namespace? 
I don't mean copying these elements into the atom namespace, but 
actually use them in the dcterms namespace.

- Sam Ruby

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Fri, 23 Jul 2004 14:22:25 -0400

> - For tools to import and export entries, including their entire 

Allow multiple revisions of the same entry in the same feed, with the 
same id, with different modified or updated dates. Obviously this 
should be discouraged, or not allowed at all, in syndication.

> treat a "minor revision".

Immutable id's for all revisions, as are already in the spec.

> be issued exactly once, with an immutable 'issued' date.

Can you fill us in why this case might need to be handled differently 
from entries that change?

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 18:30:14 +0200

> - For tools to import and export entries, including their entire editing

A supersede mechanism.

> treat a "minor revision".

A supersede mechanism.

> - Organizations/tools/people to support the use case that an entry may  
> only be issued exactly once, with an immutable 'issued' date.

A supersede mechanism plus specification text that says that 'issued' is  
immutable.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»