I'm confused; the current proposal (below) doesn't have that text in
it; for example, the definition of previous is:
A stable URI that, when dereferenced, returns a feed document
containing a set of entries that sequentially precede those in the
current document. This can be thought of as specific to those
entries; in other words, it represents a fixed section of the feed,
rather than a sliding window over it. Note that the exact nature of
the ordering between the entries and documents containing them is
not defined by this relation; i.e., this relation is only relative.
On 18/10/2005, at 12:14 PM, Robert Sayre wrote:
On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
On 18/10/2005, at 11:38 AM, Robert Sayre wrote:
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn't at all clear that the
OpenSearch document did that.
I think maybe we have a difference of opinion on what's needed here.
I vastly prefer your first definition of next/prev. The "should not
change over time" stuff is not testable. For example, a template
change in Movable Type followed by a "Rebuild All" makes every single
archive change. As a client implementor, I can't see how the the
follwing text helps me:
"The set of entries in this document should not change over time;
i.e., this link points to a stable snapshot of entries, or an archive
of feed entries."
I think what you're describing is a sensible server implementation
strategy, because once the URI is visited, it should return 304 in the
future.
Robert Sayre
--
Mark Nottingham http://www.mnot.net/