Subject: Re: Propose partial consensus on dates

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 01:00:49 +0200

>	Updated: At least one byte has changed and the publisher considers
> the change to be of such significance that readers should consider reading
> the entry even if they had read an earlier version. Atom:updated would be
> used when adding additional paragraphs to an entry, modifying a position
> taken in an entry, modifying the content in such a way that the semantics
of
> the entry (not just it's syntax) has changed.

Disregarding "atom as feed format", and looking at the "atom as archive
format": How is one going to represent a complete history of revisions with
this model, when multiple, and differing entry:id's are disallowed?

-- 
Arve Bersvendsen

---

From: Eric Scheid <[email-masked]>
Date: Thu, 22 Jul 2004 10:37:52 +1000

> this model, when multiple, and differing entry:id's are disallowed?

perhaps in the same way that an archive format could encapsulate an archive
of the comments on entries ... as a separate feed specific to that entry.

    <link rel="versions" type="application/atom+xml" ... />

this also has the side effect of only having the current version in the
archive ... handy if you want to import that archive into an environment
that doesn't support entry versions without it having to understand any
'supercedes/obsolete' meta-tagging.

If a tool wants to import all versions, it can still do so.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 22 Jul 2004 09:11:15 -0500

"Arve Bersvendsen" <[email-masked]> writes:

> Disregarding "atom as feed format", and looking at the "atom as
> archive format": How is one going to represent a complete history of
> revisions with this model, when multiple, and differing entry:id's
> are disallowed?

We can say "atom as an archive format" can have multiple entry
instances with the same atom:entry/atom:id (while also having, say,
different atom:entry/formalpub:version-id URIs).

However, disregarding whether a formal publishing model should be in
the core of Atom, if we recognized a formal publishing model as a
first class application of Atom (of course, why wouldn't we?) we
should consider the issue of duplicate atom:entry/atom:id's in the
same dynamic feed as well and propose a solution for informal Atom
clients to disregard all but the most-recently modified/updated entry.

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Fri, 23 Jul 2004 09:28:33 +1000

> this model, when multiple, and differing entry:id's are disallowed?

Would you want to though? Yes, you would want all versions available to a
thing that can handle all versions, but what happens if you try importing
that all-versions-archive into a thing that doesn't keep multiple revisions
of the same entry? It's going to get messy.

A diversion for a moment ... how would you import an archive of entries and
all the comments on those entries? The simplest model would be to have a
link in every entry which leads to an archive feed of comments for that
entry. This way an importer doesn't have to try disambiguating comment
entries from top level entries, it doesn't even have to process comments if
it doesn't want them.

Back to entry revisions... consider putting only the latest data for an
entry in the archive feed, and putting a link in each archive entry which
leads to a new archive feed specific to that entry which holds all the
previous versions of that entry. Viola! A dumb environment would import just
the latest entries, while a smarter environment has the option of importing
the archive of versions too.

Only one hiccup - would every entry in a feed-versions-archive have the same
id? The way I would write the code would be such that archive-versions get a
versioned id - the original id plus some versioning suffix. Anything
pointing to the original version would still work, and nothing should be
pointing to the specific version as yet anyhow. You could of course point to
the specific version if it was revealed somehow (diveintomark has a glimmer
of this), and in that case you'd want to use the id specific to that
specific version. 

e.