James Holderness wrote:
>
> Just looking at that example, it seems to me that an aggregator that
> implements Microsoft's simple list extensions would get a full-featured
> representation of that feed without having to know anything at all about
> feed rank and feed history.
>
That's part of the point, actually. The extensions can work
cooperatively with or independently of one another.
> So why bother with them?
The Feed history <complete /> element and SLE's
<cf:treatAs>list</cf:treatAs> directly compete with one another, with
the exception that treatAs also defines that ordering of the entries is
important.
Feed Rank operates orthogonally to both.
> I'm sure you can come up with cases which couldn't be handled perfectly
> by SLE (which I'd be the first to admit is a pretty lousy spec), but
> it's out there now and it more or less works. Does feed rank really
> offer you so much more that it justifies a competing extension?
>
To understand where the value of Feed Rank comes in, consider adding
additional ranking dimensions to each entry. For instance, an entry
might contain a position rank, an average five star review rank, a
average-review-from-my-friends rank, a critics ranking, a popularity
ranking (e.g. number of times the movie has been rented in the last
month), etc.
<entry>
...
<r:rank label="Queue Position"
scheme="tag:example.org,2006:queue">1</r:rank>
<r:rank label="Average reviews (everyone)"
domain="tag:example.org,2006:reviews"
scheme="tag:example.org,2006:reviews/all">3.5</r:rank>
<r:rank label="Average reviews (friends)
domain="tag:example.org,2006:reviews"
scheme="tag:example.org,2006:reviews/friends">2.5</r:rank>
<r:rank label="Average reviews (critics)
domain="tag:example.org,2006:reviews"
scheme="tag:example.org,2006:reviews/critics">3.0</r:rank>
<r:rank label="Total rentals this week"
domain="tag:example.org,2006:rentals"
scheme="tag:example.org,2006:rentals/week">5</r:rank>
<r:rank label="Total rentals this month"
domain="tag:example.org,2006:rentals"
scheme="tag:example.org,2006:rentals/month">50</r:rank>
<r:rank label="Total rentals this year"
domain="tag:example.org,2006:rentals"
scheme="tag:example.org,2006:rentals/year">500</r:rank>
<r:rank label="Current queues (everyone)"
domain="tag:example.org,2006:queued"
scheme="tag:example.org,2006:queued/all">40</r:rank>
<r:rank label="Current queues (friends)"
domain="tag:example.org,2006:queued"
scheme="tag:example.org,2006:queued/friends">2</r:rank>
...
</entry>
In this sense, feed rank shares a closer relationship to atom:category
than it does to SLE.
With SLE, each sort key can appear only once within an entry. In order
to implement the example above, you would have to create a new
namespaced extension element for each dimension you wish to sort on (not
necessarily a bad thing, but opens the door to having multiple
independent and non-interoperable vendor-specific namespaces that all
implement the same basic feature in slightly different ways). With Feed
Rank, we can have as many dimensions as we want, with a consistent
definition and processing model for each, without having to define a new
namespaced extension element for each dimension.
Further, SLE operates only on a single feed document. Feed Rank is
capable of spanning multiple feed and/or entry documents, regardless of
whether they are pages in a single logical feed or are completely
independent of one another. For instance, a school could offer one feed
for each class in which each entry represent a test grade for an
individual student.
<feed>
<title>Class 1</title>
...
<entry>
...
<r:rank label="1"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">1.0</r:rank>
</entry>
<entry>
...
<r:rank label="1-"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">1.3</r:rank>
</entry>
</feed>
<feed>
<title>Class 2</title>
...
<entry>
...
<r:rank label="4"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">4.0</r:rank>
</entry>
<entry>
...
<r:rank label="4-"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">4.3</r:rank>
</entry>
</feed>
<feed>
<title>Class 3</title>
...
<entry>
...
<r:rank label="1"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">1.0</r:rank>
</entry>
<entry>
...
<r:rank label="2+"
domain="tag:example.org,2006:grades"
scheme="tag:example.org,2006:grades">1.7</r:rank>
</entry>
</feed>
Using Feed Rank, you could choose to sort the student entries within a
single class feed (e.g. who are the top students in Class 1), or produce
a combined view spanning all three feeds (e.g. who are the top students
at the school).
Also, with the SLE, the ordering is dependent on the feed in which the
entry appears. Pass the entries through an aggregator (e.g. Sam's
http://planet.intertwingly.net) and the order of the entries may change,
breaking your list. With Feed Rank, the ranking value is attached to
the entry, meaning that even if the entries are copied into aggregate
feeds, reordered, etc, the original sort order can be reconstructed.
Again, however, Feed Rank is not intended to compete with the simple
list extensions. They serve different purposes. SLE defines a
processing model for individual feed documents whose entries represent a
sorted list; Feed Rank defines a way of assigning numeric rankings to
entries to facilitate sorting and grouping.
- James
> Regards
> James
>
> James M Snell wrote:
>> Just a quick heads up. To illustrate a simple example of feed rank bein
>> used, I put together an xslt that renders my Netflix Queue as an Atom
>> feed using the feed rank, feed history and MSFT simple list extensions.
>>
>> http://tinyurl.com/nxzgh
>
>
