Subject: Possibly contrary statements in Atompub and feed history I-Ds

From: Nikunj Mehta <[email-masked]>
Date: Tue, 21 Aug 2007 09:18:43 -0700

§10.1 of AtomPub I-D expects collection partial lists aka pages to be 
/lossless/.

    In addition, partial list feeds MAY contain link elements with "rel"
    attribute values of "next", "previous", "first" and "last" that can
    be used to navigate through the complete set of entries in the
    Collection.

§3 of Feed history I-D expects paged feeds to be lossy

   Paged feeds are lossy; that is, it is not possible to guarantee that
   clients will be able to reconstruct the contents of the logical feed
   at a particular time.  Entries may be added or changed as the pages
   of the feed are accessed, without the client becoming aware of them.

   Therefore, clients SHOULD NOT present paged feeds as coherent or
   complete, or make assumptions to that effect.

Further, in the same section, the same link "rel" attribute values are 
used in paged feeds for feed history

    The feed documents in a paged feed are tied together with the following link relations:

       o  "first" - A URI that refers to the furthest preceding document in
          a series of documents.
       o  "last" - A URI that refers to the furthest following document in a
          series of documents.
       o  "previous" - A URI that refers to the immediately preceding
          document in a series of documents.
       o  "next" - A URI that refers to the immediately following document
          in a series of documents.

First obvious question - Is the feed history I-D being contradictory to 
the AtomPub I-D?
Second question - which I-D is the specification for the above link 
"rel" attribute values?

Thanks,
Nikunj

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 21 Aug 2007 20:23:09 +0200

> §10.1 of AtomPub I-D expects collection partial lists aka pages to be

Seems like we don't have the same definition of lossless then...

Partial lists in AtomPub are subject to the following constraint:
    The first such partial list returned MUST contain the most recently
    edited member Resources and MUST have an atom:link with a "next"
    relation whose "href" value is the URI of the next partial list of the
    Collection. This next partial list will contain the next most recently
    edited set of Member Resources (and an atom:link to the following
    partial list if it exists).

>    of the feed are accessed, without the client becoming aware of them.

Conclusion: I don't see any conflict their.

-- 
Thomas Broyer

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 21 Aug 2007 13:50:03 -0700

> Seems like we don't have the same definition of lossless then...
Allow me to clarify. A lossless paging is the following (this is my 
interpretation of §10.1 of AtomPub I-D):

    The partial list of entries obtained by GETting the collection's URI
    combined with partial lists obtained by following the rel="next"
    links in each of those partial lists MUST provide the snapshot of
    all of a collection's entries *as of the time *when the server
    responded to the GET request on the collection URI.

Per §3 of the feed history I-D,

    it is not possible to guarantee that  clients will be able to reconstruct 
    the contents of the logical feed /at a particular time/

(emphasis mine)

On the contrary lossy paging occurs when there is no such guarantee, 
i.e., navigating between partial lists might produce the same entry 
twice or more, might skip an entry completely because it "disappeared in 
the boundary between pages".
>     partial list if it exists).
If I am interpreting this right (without any formal model of course), 
then "next" implies the immediately "next most recently edited". To me, 
that means lossless.
>>    of the feed are accessed, without the client becoming aware of them.
I respectfully disagree with this interpretation per my argument above. 
If the definition of partial lists and paging results in collection 
feeds being lossy, then how would we guarantee any synchronization of 
paged collections?
> Conclusion: I don't see any conflict their.
Sorry I have come a little late to the feed history I-D party, but it 
looks like this spec is not strongly consistent with AtomPub (and the 
fact that the two don't even refer to each other's existence stinks, IMHO).

Furthermore, can someone point out which RFC or I-D defines link 
rel="first", link rel="last", link rel="next" and link rel="previous"?

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 22 Aug 2007 08:44:05 +0200

>     responded to the GET request on the collection URI.

OK, so we don't have the same interpretation. It means this means
clarification in the spec (is it too late?).

> the boundary between pages".

Yup.

> then "next" implies the immediately "next most recently edited". To me,

As partial lists are not defined to be "stable", they might be
changing over time. At the time you retrieve the first partial list,
the second partial list contains the "next most recently edited". But
between the retrieval of the first partial list and the time you
retrieve the second one, this one might have changed.

> feeds being lossy, then how would we guarantee any synchronization of

You cannot guarantee synchronization without an atomic operation or
paging a snapshot. Requiring servers to create "paged snapshots" (i.e.
as per your interpretation of atompub-protocol-17) would have too much
implications: servers would need to remember each and every "edit"
(app:edited) of all the entries.

The "partial list" thing is the Simplest Thing That Could Possibly
Work. If you want a reliable synchronization, then either:
 1. use another mechanism (RFC3229 w/ Feeds?)
 2. re-start synchronization from the Collection URI partial list
until you no longer need to follow the rel="next" link

> rel="first", link rel="last", link rel="next" and link rel="previous"?

http://www.iana.org/assignments/link-relations.html says its Feed History.

-- 
Thomas Broyer

---

From: "James Holderness" <[email-masked]>
Date: Wed, 22 Aug 2007 13:14:25 +0100

> http://www.iana.org/assignments/link-relations.html says its Feed History.

I've been meaning to ask about that. When those link relations were first 
defined, I thought the idea was that they would be fairly generic so that 
they could be used in various situations. The link definitions themselves 
make no reference to things like sort order or the stability of the 
documents to which they point. That should be up to the spec that uses 
them - for example AtomPub partial lists are typically ordered by 
app:edited, but feed history paged feeds make no recommendation either way.

However, having the IANA registration point to the feed history draft 
implies things about those relations which were never intended. IMHO that's 
a bad thing. The feed history draft describes one possible use of those 
links, but certainly not the only one. There should be no obligation for 
other specs to be semantically identical in their usage.

Regards
James

---

From: "Daniel E. Renfer" <[email-masked]>
Date: Thu, 23 Aug 2007 11:06:01 -0400

Would it be safe to assume that if I retrieve two pages of a paged feed,
and the atom:updated element for the feed is unchanged then I am indeed
seeing a complete history of that feed?

If I retrieve page 1, record the updated time, and retrieve page 2 and
the updated time has changed, then I know new entries have been added to
the feed since I got page 1. There may be some entries in page 2 that I
previously saw in page 1. (The ones that have overflown to the next
page) I'll have to re-retrieve page 1 to get the new entries.

If I retrieve page 2 first, and then get page 1, and the updated value
has changed, I know that I am missing some entries. They were on page 1
when I first got page 2, but are now on page 2. (or higher) I will have
to re-retrieve the next page(s) until I find an entry I recognize.

If the updated value is unchanged, then nothing has been added, removed,
or modified in the feed. I can consider my view of the feed to be complete.

Am I correct in this assumption?

---

From: Eric Scheid <[email-masked]>
Date: Fri, 24 Aug 2007 03:16:19 +1000

> Am I correct in this assumption?

sounds about right.

unless the server doesn't generate the paged feed dynamically, instead
simply archiving the pages as they accumulate (but still generating the
top-most page dynamically) ... in which case they might serve up the page as
it was when it was archived, including the as it was then atom:updated value
for the feed.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Aug 2007 10:09:32 +1000

Does atom:updated apply to *this* feed document, or the whole,  
logical feed?

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Thu, 23 Aug 2007 18:07:27 -0700

Good question. Unfortunately the spec does not give a very clear answer.

   The "atom:updated" element is a Date construct indicating the most
   recent instant in time when an entry or feed was modified in a way
   the publisher considers significant

Given that the RFC does not really have any notion of a "logical feed",
the only reasonable interpretation I think we can make is that it
applies only to *this* feed document.

- James

Mark Nottingham wrote:
> 
> Does atom:updated apply to *this* feed document, or the whole, logical
> feed?
> 
>

---

From: "Eric Larson" <[email-masked]>
Date: Fri, 24 Aug 2007 00:45:23 -0500

Hi,

> applies only to *this* feed document.

I would actually assume that it means the last time the collection as
a whole was updated.

Simply from a logical perspective, if I want to see when the specific
feed was updated, it seems the atom:updated elements in the entries
can tell me that. Also, the atom:updated in the in the feed seems to
be similar to the atom:title of the feed, which I would assume would
have meaning relative to the collection and not simply the current
feed. For example, if I were implementing paging and the using a GET
variable:

http://host.com/blog/feed/index.atom?page=3&limit=10

It seems logical that the collection information found in the feed
would be consistent across each paged entry.

I mention all this simply b/c as James says, it is not entirely clear,
so my suggestions above are really just my two cents as to what folks
should do as a best practice.

What do you all think?

Eric

---

From: James M Snell <[email-masked]>
Date: Thu, 23 Aug 2007 22:49:57 -0700

RFC4287 has no concept of a "Collection". Collections are only
introduced by Atompub.  And if you look at the Atompub spec, there's no
mention of atom:updated at all, so it's still entirely up in the air and
subject to individual interpretation.

- James

---

From: "Joe Gregorio" <[email-masked]>
Date: Sat, 25 Aug 2007 10:30:15 -0400

> Good question. Unfortunately the spec does not give a very clear answer.

What are you talking about?

http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#listing-collections

""" The first such partial list returned MUST contain the most
recently edited member Resources and MUST have an atom:link with a
"next" relation whose "href" value is the URI of the next partial list
of the Collection. This next partial list will contain the next most
recently edited set of Member Resources (and an atom:link to the
following partial list if it exists)."""

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: James M Snell <[email-masked]>
Date: Sat, 25 Aug 2007 09:29:26 -0700

Yes, I'm very familiar with that part of the spec.  The quote you
provide still does not answer the question:

  "Does atom:updated apply to *this* feed document,
   or the whole, logical feed?"

Neither RFC4287 or Atompub provide a clear answer to this question.

- James

---

From: "Joe Gregorio" <[email-masked]>
Date: Sat, 25 Aug 2007 13:44:49 -0400

>    or the whole, logical feed?"

Ah, we might be talking past each other about two
different scenarios.

This question is answered for "app:edited" in a Collection Feed,
i.e. in the context of an AtomPub Collection Feed only.
It does not answer the question for "atom:updated" in
an 'Archived Feed'.

"""The Entries in the returned Atom Feed SHOULD be ordered by their
"app:edited" property, with the most recently edited Entries coming
first in the document order. """

So every Feed Document that makes up a collection has it's entries
ordered via "app:edited", and the quote I gave earlier states that:

"""This next partial list will contain the next most
recently edited set of Member Resources (and an atom:link to the
following partial list if it exists)."""

So there is a total ordering of entries across all the partial feed
documents of entries by "app:edited".

Would it have been clearer if all the text were located in one
place in the spec? Yes.

Does it matter that we didn't use the term "logical feed"? No.

Is there a conflict with the Feed History I-D? No, since the
   rel term "next", and others are defined in terms of a "Paged Feed"
   and not an "Archived Feed". The former having "some kind" of
   order, the second having an explicit ordering by "atom:updated".

Is there ambiguity in the Feed History I-D as to whether
the entries in each feed document are ordered by atom:updated? Yes,
  but I'm not sure that it matters.

   -joe

---

From: Nikunj Mehta <[email-masked]>
Date: Mon, 27 Aug 2007 07:39:47 -0700

>    order, the second having an explicit ordering by "atom:updated".
When you see a feed can you tell whether it is a "paged feed" or a 
"collection feed"? I can't.

In that case, how can you correctly interpret rel="next" as "paged feed" 
allows lossy feed paging and "collection feed" requires lossless paging?