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/

Reply via email to