Antone Roundy wrote:
I think a ranking without a domain is pretty much useless--or at least
likely to lead to problems downstream--so that case doesn't need to be
covered. More on that below.
Agreed.
xhtml:html
...
xhtml:body
atom:feed
atom:idFeed1/atom:id
This could all get rather complicated very quickly. My primary objective
is to address known use cases for ordered feeds (my netflix queue
feed[1] for example), most of which are structured as complete datasets
that are non-incremental in nature. I'm not convinced that I necessarily
want to
On Wednesday, September 21, 2005, at 11:43 PM, James M Snell wrote:
feed xmlns:i=urn:ranking
i:domain{domain}/i:domain
I was thinking yesterday of suggesting that feed/id be used the way
you're using i:domain. Which is better is probably a matter of whether
ranking domains that span multiple
James M Snell wrote:
This could all get rather complicated very quickly. My primary objective
is to address known use cases for ordered feeds (my netflix queue feed[1]
for example), most of which are structured as complete datasets that are
non-incremental in nature.
I realise that this
Antone Roundy wrote:
On Wednesday, September 21, 2005, at 11:43 PM, James M Snell wrote:
feed xmlns:i=urn:ranking
i:domain{domain}/i:domain
I was thinking yesterday of suggesting that feed/id be used the way
you're using i:domain. Which is better is probably a matter of whether
ranking
On Thursday, September 22, 2005, at 10:20 AM, James M Snell wrote:
Antone Roundy wrote:
I was thinking yesterday of suggesting that feed/id be used the way
you're using i:domain. Which is better is probably a matter of
whether ranking domains that span multiple feeds will be useful or
not.
On 14/09/2005, at 1:06 PM, David Powell wrote:
I'm probably on my own, but I expected Atom's statement that This
specification assigns no significance to the order of atom:entry
elements within the feed was non-negotiable and couldn't be changed
by extensions. This seems more like potential
On 14/09/2005, at 1:06 PM, David Powell wrote:
How will this interact with the sliding-window/feed-history
interpretation of feeds? The natural order assigned by this extension
seems incompatible with the implied date order that would be implied
by two feed documents, polled over some period
On 21/9/05 1:05 PM, James M Snell [EMAIL PROTECTED] wrote:
The ranking is part of the entry metadata. If an entry falls off the
feed, there is no effect on the ranking metadata. With partial feed
retrieval, ordering could be performed over the entire set of entries.
How does this help (eg)
Marking entries as having no rank sounds like a nice idea, but I don't think
it's feasible in the long run. In order to erase ranking effectively from
previous entries, the content provider needs to double their feed size
potentially. And if a user misses out on a rank update they could end
On 21/9/05 9:35 PM, James Holderness [EMAIL PROTECTED] wrote:
Marking entries as having no rank sounds like a nice idea, but I don't think
it's feasible in the long run.
thinking more ... I think the way to handle this is that the client
application could weight the ranking with the age of
I had considered something along those lines, but it seemed to me to be a
bit vague. I suspect it would produce adequate results in the majority of
cases, but I'd prefer something that gave the content provider finer
control. I like the idea of being able to say exactly where in a feed an
Eric Scheid wrote:
On 15/9/05 6:06 AM, David Powell [EMAIL PROTECTED] wrote:
Eg - An Atom library or server that doesn't know about this extension
is free to not preserve the entry order, and yet to retain the
fi:ordered / element, even though this will have corrupted the data.
James M Snell wrote:
Complete example
feed
...
i:ranking default=yes order=descendingpriority/i:ranking
i:ranking order=ascendingindex/i:ranking
i:ranking
order=descendinghttp://www.example.com/ranking/foo/i:ranking
entry
...
idC/id
i:rank scheme=priority10/i:rank
i:rank scheme=index3/i:rank
On 21/9/05 5:18 AM, James M Snell [EMAIL PROTECTED] wrote:
For instance
feed
entry
...
i:rank10/i:rank
/entry
entry
...
i:rank5/i:rank
/entry
/feed
What happens when entries fall off the bottom ... do their rankings
expire? How does that work with the
Eric Scheid wrote:
On 21/9/05 5:18 AM, James M Snell [EMAIL PROTECTED] wrote:
For instance
feed
entry
...
i:rank10/i:rank
/entry
entry
...
i:rank5/i:rank
/entry
/feed
What happens when entries fall off the bottom ... do their rankings
expire? How does that work with
On 15/9/05 6:06 AM, David Powell [EMAIL PROTECTED] wrote:
Eg - An Atom library or server that doesn't know about this extension
is free to not preserve the entry order, and yet to retain the
fi:ordered / element, even though this will have corrupted the data.
very good point.
e.
Monday, September 12, 2005, 5:55:20 PM, James M Snell wrote:
I've updated the draft that defines an extension that can be used to
indicate that the order of entries within a Feed should be considered
significant.
How will this interact with the sliding-window/feed-history
interpretation
David,
Excellent comments.
David Powell wrote:
How will this interact with the sliding-window/feed-history
interpretation of feeds? The natural order assigned by this extension
seems incompatible with the implied date order that would be implied
by two feed documents, polled over some
I've updated the draft that defines an extension that can be used to
indicate that the order of entries within a Feed should be considered
significant.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-02.txt
Example,
feed xmlns=http://www.w3.org/2005/Atom;
I've updated the draft that defines an extension that can be used to
indicate that the order of entries within a Feed should be considered
significant.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-02.txt
Example,
feed xmlns=http://www.w3.org/2005/Atom;
21 matches
Mail list logo
