Thomas Broyer wrote:
2007/8/21, Nikunj Mehta:
§10.1 of AtomPub I-D expects collection partial lists aka pages to be
/lossless/.
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 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).
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.
So by definition, they are lossy, by the following definition of lossy:
§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.
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"?
