On Oct 17, 2005, at 2:20 AM, Eric Scheid wrote:
On 17/10/05 5:09 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
1. Which relationship, next or prev, is used to specify a link
backwards in
time to an older archive. Mark Nottingham's Feed History proposal
used prev.
Mark Pilgrim's XML.com article used next.
I'd prefer that our use of 'prev' and 'next' be consistent with
other uses
elsewhere, where 'next' traverses from the current position to the
one that
*follows*, whether in time or logical order. Consider the use of
'first/next/prev/last' with chapters or sections rendered in HTML.
...so do you follow forward through time or backward? Is the
starting "current position" "now" or the "the beginning of time"?
Especially if we're talking about history, following backward makes
as much sense as following forward.
I prefer "next" to go back in time (if temporally ordered--from the
most current chunk to the next most current chunk) or to less
significant pages (in things like search results). But I'll probably
have to stop and think what "next" means in temporally ordered feeds
from time to time since it'd be the reverse of temporal order.
2. Are next and prev both needed in the spec if we only require
one of them
to reconstruct the full history?
Knowing that the most recently published archive won't likely
remain the
most recently published archive, there will be use cases where it's
better
to reconstruct the full history by starting at the one end which is
fixed.
Not much sense starting at the other end which is constandly shifting.
Is this only going to be used to reconstruct full history? What
about just reconstructing the last 3 months (in which case you'd want
a link from closer to the live end to close to the fixed end), or
reading from the beginning before deciding whether to continue
reading what comes later (in which case you'd want a link from closer
to the fixed end to closer to the live end).
3. Are the first/last relationships needed?
See (2) above for 'first'. Meanwhile 'last' could be followed by a
user to
jump ahead to the end of the set of archives to see if the butler
did it.
Who said 'first/next/prev/last' would only be used by machines?
As mentioned above, there may be cases where you'd prefer to start at
either the fixed or live end, so as long as complete feed
reconstruction isn't the only goal, I'd say yes.
But what's "first"? It'd be the top results in a search feed, but
would it be the start of time or the start from the present (before
possibly traveling backward through time) in a temporally ordered
feed? Making it the start of time would prevent it from matching up
well with how significance ordered feeds match up (ie. does start
point to the thing you'd most likely want to see if you subscribed to
the feed?) If we're not careful, we'll be traversing out of "first"
through "prev" and "last" through "next"!
4. Is the order of the entries in a feed relevant to this proposal?
not to this proposal.
If you mean not just the order within each chunk of the feed, but the
order of the chunks, then not central, but certainly related. Two
cases come to mind:
1) A chain of temporally ordered chunks in the history of a feed
where new entries are tacked onto the end.
2) Search results, where the order of everything all along the entire
chain shifts around all the time.
If you're not going to reconstruct the whole thing, then your
decision function for when to stop may have to be different depending
on how things are ordered.
BTW, case 2 destroys the idea of a "fixed" end and a "live" end.
Having a means to indicate what the ordering is might make it easier
to make the distinction between "next" and "prev" more intuitive.
I'm not sure how else we're going to reconcile terminology for
significance and temporally ordered feeds.
5. Is the issue of whether a feed is incremental or not (the
fh:incremental
element) relevant to this proposal?
non-incremental feeds wouldn't be paged, by definition, would they?
This week's top ten on the first page, last week's ten on the second
page...
Since this proposal is defining a paging mechanism, I think that what
each page represents is relevant. Is it an earlier part of the feed
or an earlier state of the feed?
6. What to name the link relation that points to the active feed
document?
subscribe, subscription, self, something else?
'subscribe'
I just noticed something about the definition of "self" in the format
spec. In one place it says:
o atom:feed elements SHOULD contain one atom:link element with a
rel
attribute value of "self". This is the preferred URI for
retrieving Atom Feed Documents representing this Atom feed.
Does that mean that it's the preferred <option>subscription</option>
URI, or the preferred place to retrieve <option>this chunk</option>
of the feed history? The format spec didn't define paging, so it
didn't contemplate talking about chunks of the feed--so here it
sounds like it's talking about a subscription URI (else it would say
"for retrieving this Atom Feed Document."). Moving on...elsewhere,
the spec says this:
3. The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.
In a historical chunk, wouldn't that have to mean "this chunk"?
Can "self" be polymorphic--the subscription URI in the live end of a
feed, and "this chunk" in a historical chunk? Can an extension speak
authoritatively about the meaning of something from the core spec?
I'd think that if the feed history extension is an official Working
Group document, then it wouldn't be out of line to use it to nail
down the meaning of "self" more tightly, especially since we don't
currently seem to have agreement about the meaning of "self". Let's
let "self" mean "a place to get what you're looking at right now,
which may or may not change over time", and add "subscribe" with it's
obvious meaning. If a document contains both and they're different,
then "self" should NOT be used to subscribe (although that arguably
conflicts with the first part of the spec quoted above). If "self"
weren't a "SHOULD", I'd think this would lead to "self" being used
only in historical chunks, and "subscribe" being used in both
historical chunks and live documents to point to the subscription
URI, which would be nice and clean. But since "self" is a "SHOULD",
I'm afraid this will lead to "self" pointing to live documents in
documents without a "subscribe" link, and historical chunks in
documents that do have "subscribe". A bit ugly, but is there a
better way available to us?
