Subject: On PaceDateSamRuby and PaceDateKenMacLeod

From: "Andreas Sewe" <[email-masked]>
Date: Thu, 12 Aug 2004 23:40:07 +0200

Sorry, I accidentally hit the send button. Please ignore my previous posting.

There I wrote, rather incompletely:
> Paul Hoffman wrote:
> > In your comments on them, please state what style hat you are wearing
> > (client developer, content aggregator, publisher, and so on) and
> > which you think best fits your needs. It is OK to talk about your
> > wants as well, but please focus on needs, given that this is for the
> > Atom *core* document.

> On top of my lurker's hat I am wearing a publisher's one. Out of the
> original proposals I liked PaceDateSamRuby [1] best, but now there is
> PaceDateKenMacLeod [2] as well which I like even better. And here's why:

> Personally I would rather see the dcterms used as an extension instead of
> being redefined in the atom namespace.

Especially PaceDateSamRuby with its single date, which, if I understood the
intended purpose of atom:d correctly, is aimed mostly at the presentation of
entries to the user. But then again I might have read too much into "Consumers
MAY chose to sort based on this value". To this user-agent centric date the
dcterm dates are mostly orthogonal as they reflect the publishing process more
than the user/presentation aspect.

At any rate, this orthogonality is IMHO a good thing, whereas
PaceDateAntoneRoundy and PaceDateAsbjornUlsberg both define a number of dates
very similar to those defined by dcterms while not including other dates also
defined by dcterms. Why preferring one subset of dcterm dates over another?

Now PaceDateKenMacLeod too includes a date which is defined similarily in
dcterms: atom:e (which, at least to me, looks similar to dcterms:modified). It
has additional implicitions though, because it is meant as some kind of entry
versioning mechanism:

"Publishers may provide more than one instance or version of the same
atom:entry within the same atom:feed (ie. with equivalent atom:id values),
consumers MAY choose to only record, process, or present the atom:entry with
the latest atom:e value."

I'm not sure I like this. IMHO a real supersedes mechanism would be better.

> So, +1 on PaceDateKenMacLeod, +0.5 on PaceDateSamRuby.

So please allow me to changes this to +1 on PaceDateSamRuby only, taking my
concerns about entry versioning disguised as atom:e into account.

Regards,

Andreas Sewe

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 00:58:07 +0200

On Thu, 12 Aug 2004 23:40:07 +0200, Andreas Sewe  
<[email-masked]> wrote:

> "Consumers MAY chose to sort based on this value". To this user-agent
> centric date the dcterm dates are mostly orthogonal as they reflect
> the publishing  process more than the user/presentation aspect.

Is PaceDateSamRuby and PaceDateKenMacLeod specifying a subjective? I can't  
read that into the specification text in either of them. If it's meant to  
be subjective, and that all objective more publishing process-related  
dates should go in the DCTerms namespace, the paces should state so. Now  
they only specify that the DCTerms dates are needed because the atom:*  
date(s) can't represent «created», for example.

When the specification needs to point to external date elements to cater  
for such a simple use case as «created», I think it's a good reason to  
include «created» (whatever we may choose to call it) in the specification.

> Why preferring one subset of dcterm dates over another?

Because some are more useful than others. The ones specified in my pace(s)  
at the moment, are the ones I would like to see used as soon as possible.  
The other DCTerms dates aren't that important, but if consumers or  
producers of Atom start asking for them, we should of course think about  
including them in the Atom namespace and define their uasge in Atom  
(version 1.1 for example).

> I'm not sure I like this. IMHO a real supersedes mechanism would be  

That's something I can agree with.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 13 Aug 2004 01:01:56 +0200

On 12 Aug 2004 17:41:05 -0500, Ken MacLeod <[email-masked]> wrote:

> Although I'm concerned about the irreversability of this decision with
> respect to versioning, if no one sees value in either case I'm fine
> with withdrawing the proposal.

I think versioning is important, and I think Atom should not be locked  
 from allowing extensions to define versioning. I've slowly begun to think  
that versioning can be done without changing the atom:id, and that a  
version:id is a good way to go. Still, I don't know how such a mechanism  
can impact the current Atom core specification. If we need to specify e.g.  
that atom:id MAY appear several times in a feed to cover future  
revisioning systems, we should do so.

---

From: Ken MacLeod <[email-masked]>
Date: 12 Aug 2004 17:41:05 -0500

"Andreas Sewe" <[email-masked]> writes:

> Now PaceDateKenMacLeod too includes a date which is defined
> similarily in dcterms: atom:e (which, at least to me, looks similar
> to dcterms:modified). It has additional implicitions though, because
> it is meant as some kind of entry versioning mechanism:
> 
> "Publishers may provide more than one instance or version of the
> same atom:entry within the same atom:feed (ie. with equivalent
> atom:id values), consumers MAY choose to only record, process, or
> present the atom:entry with the latest atom:e value."
> 

Earlier, Dare Obasanjo <[email-masked]> wrote:
> Using dates as a versioning mechanism seemed like a hack to me. I
> definitely oppose all efforts to conflate the date issue with
> versioning.

I'd like to clarify that PaceDateKenMacLeod's atom:e is not and is not
intended to be a versioning mechanism (by itself it can't be, for a
variety of reasons).

As one of its use cases, however, it does allow a future extension to
define a versioning mechanism that will work with Atom 1.0 clients by
virtue of telling Atom 1.0 clients what to do when they see more than
one entry in the same feed with the same atom:id: only use the latest.

Although that's not a strong current use case (at least our folks who
desire versioning have seemed to have backed off on requesting
multiple entries with the same story id), it's also one we can't
change our minds on in the future and remain backwards compatible.  An
alternative proposal for versioning suggests a more significant
backwards incompatibility: changing the atom:id itself for new
versions.

The other principle use case is to mark a possible change in the entry
that gives a consumer a first indication of whether they need to do
any further processing on the entry.  However, it's a weak indicator
since most processors have the time to hash every entry anyway.

  -- Ken MacLeod