Subject: FYI: Updated Index draft

From: James M Snell <[email-masked]>
Date: Mon, 12 Sep 2005 09:55:20 -0700

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"
      xmlns:fi="http://purl.org/syndication/index/1.0">
  ...
  <fi:ordered sort="descending" />
  <entry>
    <id>tag:entry:1</id>
    ...
  </entry>
  <entry>
    <id>tag:entry:2</id>
    ...
  </entry>
  <entry>
    <id>tag:entry:3</id>
    ...
  </entry>
</feed>

The fi:ordered element indicates that the order of the entries as 
presented in the feed should be considered to be significant.  The @sort 
attribute indicates the default sort order for those entries.  A value 
of "descending" indicates that the entries should be presented 
last-to-first.  A value of "ascending" indcates that the entries should 
be presented first-to-last.

- James

---

From: David Powell <[email-masked]>
Date: Wed, 14 Sep 2005 21:06:34 +0100

> indicate that the order of entries within a Feed should be considered 

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 of time.

What should be the order of a merged feed history such as this:

Poll 1:
feed(e1, e2, e3)

Poll 2:
feed(e3, e1, e5)

- where, perhaps, 3 and 1 have been updated. How do you combine
entries sorted by their natural order, with the time-ordered feed
history?

How will this interact with entry documents, eg over pubsub.

What about Atom Protocol - I can't imagine how I would publish a feed
with a given natural order. For something like the BBC feeds, some
sort of arbitrary "score" field might be more interoperable with both
entry documents, Atom protocol, and feed history.

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 Atom 1.1 material to me
- it doesn't seem to layer on top of the Atom framework so much as
slightly rewrite part of it.

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.

I think that as implemented, this extension wouldn't be safe to deploy
without must-understand extensions, which Atom 1.0 doesn't support.

Ordered feeds are a useful problem though. Indexes or scores on
entries might work better with entry documents, the protocol, and with
the Atom extension framework, but it still isn't clear how they would
interact with the sliding window.

A couple more minor points:

I'm not sure whether the descending/ascending attribute is necessary?
Given that the extension just presents a natural order (by some
unnamed ordering), why would anyone go to the trouble of presenting
the entries in reversed order, and then label them as descending; why
not just present them in ascending order to begin with?

Would it be useful for the extension to allow the natural ordering to
be named? - so if the ordering is by "Importance", or "Order of
real-life events", or something else, then it could labelled with a
URI and/or label, so that people don't have to guess the significance
of the natural order.

-- 
Dave

---

From: James M Snell <[email-masked]>
Date: Wed, 14 Sep 2005 13:37:16 -0700

David,

Excellent comments. 

>entries sorted by their natural order, with the time-ordered feed
Natural ordering and time-ordering are, by the very nature, opposing 
views -- unless of course, the natural ordering and time-ordering just 
happen to coincide with one another (by chance or design) . 

Using the terminology from Mark Nottingham's Feed History extension, 
naturally ordered feeds are likely to also be non-incremental feeds.  
For instance, my NetFlix.com Queue Feed is clearly intended to be an 
ordered, non-incremental feed.  The feed presents it's entire state.  
There is no history.  The ordering of the items in the feed is 
significant. 

I believe that it is safe to assert that ordered feeds should be 
presumed to be non-incremental.  I will hold off on making that a 
normative assertion, however, due simply because there is no evidence 
that natural ordering *can't* be preserved across multiple feeds.

>entry documents, Atom protocol, and feed history.
This is definitely something I've been thinking about -- that is, how to 
use the Atom protocol to edit an ordered collection.  Without the 
introduction of a specific metadata field within the entry itself, the 
only potential option is a pub:control parameter that specifies the 
ordering index for the entry.  At this time I simply do not yet know if 
that is the right approach. I'll need to experiment a bit more.

>slightly rewrite part of it.
As far as feed processing is concerned I agree that the ordering of 
atom:entry elements is not significant, even if the feed does contain 
<fi:ordered />.  The ordered extension is a flag that helps applications 
interpret the intention of the feed.  For example, there is a clear 
distinction of intent between my weblogs feed and my NetFlix Queue 
feed.  While both can be treated the same under the covers, having some 
sort of clue as to how the two should be presented to the user is helpful.

><fi:ordered /> element, even though this will have corrupted the data.
Agreed that this is a valid issue. Let me stew over this one.

>interact with the sliding window.
Nor is it clear how it could work in aggregation scenarios.  e.g. what 
happens if the entry contains an index and is aggregated into a feed 
that has another entry with a conflicting index?

>not just present them in ascending order to begin with?
Agreed. I actually had the same thought the other day and had a "Boy, 
that was silly" head-slap moment.

>URI and/or label, so that people don't have to guess the significance
Interesting thought.  Correct me if I'm wrong, but this would look 
something like:

  <ordered>http://www.example.com/ordered/by/priority</ordered>

With each entry having something like a corresponding priority element 
(just an example)

  <x:priority>70</x:priority>
 
Or

  <ordered>http://www.example.com/ordered/by/position</ordered>

Or ... whatever else

The bottom line would be that the URI value of the ordered element would 
indicate the ordering that should be applied to the elements.  As a side 
thought, this may solve the problem with ordering across sliding window 
feeds in at least some cases.

Very good thoughts. 

- James

---

From: Eric Scheid <[email-masked]>
Date: Thu, 15 Sep 2005 13:44:46 +1000

> <fi:ordered /> element, even though this will have corrupted the data.

very good point.

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 20 Sep 2005 12:18:53 -0700

>><fi:ordered /> element, even though this will have corrupted the data.
Indeed.  And it is a point that signals a show stopper for the approach 
taken in the draft.  As an alternative, I'm considering a alternate 
approach that places order metadata within the entry.

For instance
  <feed>
    <entry>
      ...
      <i:rank>10</i:rank>
    </entry>
    <entry>
      ...
      <i:rank>5</i:rank>
    </entry>
    <entry>
      ...
      <i:rank>15</i:rank>
    </entry>
  </feed>

The i:rank element is a non-negative integer.  Consumers of the feed may 
use the rank as a key for sorting entries.  Because different rankings 
may be relevant in different domains, the i:rank element will support a 
scheme attribute whose value is either a name or an IRI identifying a 
ranking scheme.  The built in schemes are "priority" and "index".  
"priority" is used to rank the relevative importance of the entry (the 
higher the value, the higher the importance).  "index" is used to 
specify a natural order for entries.  New scheme names can be 
standardized through IANA registration.  IRI values can be used to 
identify non-standardized schemes.  If the scheme attribute is missing, 
the value is assumed to be "index".

For instance
  <feed>
    <entry>
      ...
      <i:rank scheme="priority">10</i:rank>
      <i:rank scheme="index">1</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">100</i:rank>
    </entry>
    <entry>
      ...
      <i:rank scheme="priority">5</i:rank>
      <i:rank scheme="index">2</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">50</i:rank>
    </entry>
    <entry>
      ...
      <i:rank scheme="priority">0</i:rank>
      <i:rank scheme="index">3</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">30</i:rank>
    </entry>
  </feed>

On the feed level, metadata can be specified to indicate which ranking 
schemes are intended to be applied to the entries in the feed.  These 
are generally informative and do no rely on the actual order of the entries

For instance
  <feed>
    ...
    <i:ranking default="yes" order="descending">priority</i:ranking>
    <i:ranking order="ascending">index</i:ranking>
    <i:ranking 
order="descending">http://www.example.com/ranking/foo</i:ranking>
  </feed>

The value of the i:ranking element is the name or IRI of a ranking 
scheme.  The default attribute (value 'yes' or 'no') is used to indicate 
which ranking scheme should be considered the default.  Only one 
i:ranking with @default="yes" is allowed within a feed. The order 
attribute (value 'ascending' or 'descending') is used to indicate the 
default sort order for that ranking scheme. 

If a feed contains a particular i:ranking scheme, it's entries SHOULD 
contain corresponding i:rank elements. Entry elements that do not have 
i:rank elements for a particular scheme must be presented at the end of 
the presentation list (see the example below)

Complete example
  <feed>
    ...
    <i:ranking default="yes" order="descending">priority</i:ranking>
    <i:ranking order="ascending">index</i:ranking>
    <i:ranking 
order="descending">http://www.example.com/ranking/foo</i:ranking>
    <entry>
      ...
      <id>C</id>
      <i:rank scheme="priority">10</i:rank>
      <i:rank scheme="index">3</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">30</i:rank>
    </entry>
    <entry>
      ...
      <id>A</id>
      <i:rank scheme="priority">5</i:rank>
      <i:rank scheme="index">1</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">50</i:rank>
    </entry>
    <entry>
      ...
      <id>B</id>
      <i:rank scheme="priority">0</i:rank>
      <i:rank scheme="index">2</i:rank>
      <i:rank scheme="http://www.example.com/ranking/foo">100</i:rank>
    </entry>
    <entry>
      ...
      <id>D</id>
    </entry>
  </feed>

Ordered descending by priority): C, A, B, D
Ordered ascending by index: A, B, C, D
Ordered descending by http://www.example.com/ranking/foo: B, A, C, D

Thoughts?

- James

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 20 Sep 2005 23:05:04 +0200

> <i:rank scheme="http://www.example.com/ranking/foo">30</i:rank>
[…]
> Thoughts?
It looks more and more like Microsoft's RSS simple list extension [1], 
and I think they had the good approach (define sorts on the feed 
metadata, based on extension element values at the entry level) but a 
bad technical solution (use the extension element in a different 
context: when in cf:sort, it has a non-namespaced data-type attribute 
and its content is a "label" string, while in an entry it might not have 
attributes and its value should be of type specified by the @data-type 
attribute seen before).

Suggestions:
1. get rid of your i:rank, users will use any extension element instead 
(no more registry and you can still define "standard" priority and index 
extensions)
2. get rid of your @order attribute: users should be able to choose in 
which order they want their entries: best-ranked to least-ranked "top to 
bottom" or "bottom to top". Its the responsibility of the producer to 
provide labels and values that will be well-understood by users (e.g. 
not saying "stars" and ranking from 1 (best rank) down to 5: "stars" 
implies "number of stars", so "sort by stars in ascending order" implies 
"the highest the value, the better it is", which is not what's behind 
1=best-rank…)
3. make content of i:raking a user understandable label
4. (optional) add a data-type attribute to i:ranking (maybe rename that 
one to something related to sorting, not ranking)
5. use @namespace and @localname attributes on i:ranking to describe the 
element in entries the sort applies to (using those attributes prevent 
from using QNames in attribute values, which doesn't work great with 
prefix changes)

<feed>
<ext:sort data-type="number" namespace="http://example.com/user-review" 
localname="stars">User-reviews stars</ext:sort>
…
<entry>
<ur:stars xmlns:ur="http://example.com/user-review">1</ur:stars>
…

This, however, doesn't match "index" in the draft title any more.

What could be even better, though a lot less "simple" (and not feasible, 
see below), would be to use XPath or XPointer (XPointer has the 
advantage that you define namespace prefix bindings "inside" it , using 
the xmlns() XPointer scheme). That way, you could use any 
element/subelement and/or attribute as the value holder for the sort. 
This would require however an XPath/XPointer engine, as well as storing 
the XML DOM, or mapping XPath/XPointer to your internal feed 
representation; this is not feasible.

[1] 
http://msdn.microsoft.com/windowsvista/building/rss/simplefeedextensions/

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 Sep 2005 11:17:50 +1000

> </feed>

What happens when entries "fall off the bottom" ... do their rankings
expire? How does that work with the diff+Feed method of partial feed
retrieval?

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 20 Sep 2005 20:05:47 -0700

>expire? How does that work with the diff+Feed method of partial feed
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.

That is:
  <!-- feed 1 -->
  <feed>
    <prev>feed 2</prev>
    <entry>
      <id>A</id>
      <i:rank>1</i:rank>
    </entry>
    <entry>
      <id>B</id>
      <i:rank>3</i:rank>
    </entry>
  </feed>

<!-- feed 2 -->
  <feed>
    <entry>
      <id>C</id>
      <i:rank>2</i:rank>
    </entry>
    <entry>
      <id>D</id>
      <i:rank>4</i:rank>
    </entry>
  </feed>

The order for feed 1 is: A, B
The order for feed 2 is: C, D
Full Reconstructed order: A, C, B, D

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 Sep 2005 17:07:37 +1000

> retrieval, ordering could be performed over the entire set of entries.

How does this help (eg) bbc.co.uk order their news items in some sensible
manner?

Today, they have a couple of important stories, they indicate those entries
are rank #1, #2. Tomorrow, they have more news, but not more important than
yesterday's big news. The day after they have a new big story, it should be
rank #1. The #1 and #2 stories from two days ago have fallen off the bottom
of the feed. 

The only way out of this conundrum is that bbc.co.uk will have to update the
original #1 and #2 stories and re-rank them as much lower. If they re-rank
them as #46 and #47 then they will need to re-rank any previous entry at
those ranks to lower positions, and similarly for any other entries with
ranks which get pushed down. Eventually the entire history of the feed needs
to be re-ranked.

Unless entries can be marked as having no rank. Can they?

e.

---

From: "James Holderness" <[email-masked]>
Date: Wed, 21 Sep 2005 12:35:29 +0100

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 up 
with news items from the distant past sitting at the top of their ranking 
forever. Admittedly you already have the problem of losing items that have 
fallen off the bottom of a feed, but at least the feed remains readable. 
With a corrupted ranking system, the ranking effectively becomes useless.

One possible solution may be the use of a rank-offset tag. Let's say you 
have three items A, B and C with A being the most important (rank 1) and C 
being the least important (rank 3). You start with a rank-offset of 0 and 
your feed looks like this:

A:1 B:2 C:3 (rank-offset = 0)

Now say you want to add a new item D that falls between A and B, but you 
still only want to include 4 items in your feed. You increment the 
rank-offset to 1 and reconstruct the feed with new ranks which now look like 
this:

A:1 D:2 B:3 (rank-offset = 1)

When the client receives that feed, it automatically subtracts the 
rank-offset from each item's rank value before adding them to its database. 
So internally its list of items now look like this:

A:0 D:1 B:2 C:3

A's rank has been updated. D has been inserted. B and C remain unchanged.

From the client's point of view the ranking numbers will start going 
negative almost immediately, but as long as you treat the lowest (signed) 
value as having the highest priority it shouldn't be a problem. And the 
rankings that actually appear in the feed are always nice small positive 
integers. The rank-offset will get large over time (and I don't see how it 
can be reset), but that's just one tag.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 Sep 2005 22:58:31 +1000

On 21/9/05 9:35 PM, "James Holderness" <[email-masked]> wrote:

> 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 the item, and thus a
rank#1 item would appear near the top of the list, and then slowly drop
away.

You also get to know what the original ranking for an item is.

e.

---

From: "James Holderness" <[email-masked]>
Date: Thu, 22 Sep 2005 04:03:13 +0100

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 
item should be positioned. Then again I'm not a content provider so maybe 
that's not the sort of thing they're looking for.

---

From: James M Snell <[email-masked]>
Date: Wed, 21 Sep 2005 22:43:51 -0700

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 try to solve all of the potential problem cases that could arise 
with ordered feeds that span multiple a collection of historical feeds, 
etc. Also, I am not wishing to duplicate what Microsoft has done with 
their simple list extensions. So with that in mind, I still wish to try 
and address the issues that have been raised so here's what I have so far:

[1] http://rss.netflix.com/QueueRSS?id=P5365369447081104293883231608616881

<feed xmlns:i="urn:ranking">
<i:domain>{domain}</i:domain>
<item>
<i:rank scheme="{scheme}" domain="{domain}">{nonNegativeInteger}</i:rank>
</item>
</feed>

I drop the feed level i:ranking element and introduce a new i:domain 
element that identifies a "ranking domain" that this feed is a part of.

The i:rank element is used to specify the nonNegativeInteger rank for 
the given {scheme} for the containing element. The {domain} attribute is 
used to scope the i:rank to a specific ranking domain -- for instance, 
the priority ranking is only relevant if the entry is contained in a 
feed with a corresponding i:domain element.

The lack of a i:domain element indicates the "default ranking domain". 
Any i:rank elements that do not specify a domain attribute are 
considered to be part of the default ranking domain.

For instance, in the following example, only the first i:rank is 
relevant within the given feed. Neither of the urn:bar i:rank elements 
are relevant within this particular feed example.
<feed>
<id>tag:example.com,2005:/feed</id>
<i:domain>urn:foo</i:domain>
<entry>
<id>tag:example.com,2005:/feed/1</id>
<i:rank scheme="index" domain="urn:foo">1</i:rank>
<i:rank scheme="index" domain="urn:bar">2</i:rank>
</entry>
<entry>
<id>tag:example.com,2005:/feed/2</id>
<i:rank scheme="index" domain="urn:foo">2</i:rank>
<i:rank scheme="index" domain="urn:bar">1</i:rank>
</entry>
</feed>

Domain urn:foo ranking: tag:example.com,2005:/feed/1 then 
tag:example.com,2005:/feed/2
Domain urn:bar ranking: rag:example.com,2005:/feed/2 then 
tag:example.com,2005:/feed/1

The domain element serves multiple purposes.

1. It helps us to scope the relevance of an i:rank element within an 
entry. For instance, if an entry with an i:rank in the urn:foo domain is 
aggregated into a synthetic feed that either a) does not specify a 
ranking domain or b) specifies a different ranking domain, consumers can 
safely ignore the urn:foo i:rank.

2. It helps us to correlate ranks that span multiple feed documents. For 
instance, two separate feed documents may specify the same ranking domain.

No-Rank Entries: no-rank entries are marked by the absence of an i:rank 
element corresponding to a given scheme. For instance, in the following 
example, entry "C" is a No-Rank Entry in the Index scheme, but is ranked 
in the Priority Scheme.

<feed>
<entry>
<id>A</id>
<i:rank scheme="index">1<i:rank>
<i:rank scheme="priority">10<i:rank>
</entry>
<entry>
<id>B</id>
<i:rank scheme="index">2<i:rank>
<i:rank scheme="priority">50<i:rank>
</entry>
<entry>
<id>C</id>
<i:rank scheme="priority">20<i:rank>
</entry>
</feed>

Re: Eric's Question: "How does this help (eg) bbc.co.uk order their news 
items in some sensible manner?"

By the description given, it sounds as if the BBC ranking is more a 
ranking of relative importance than a ranking of natural order. That is, 
Top Story A has a higher importance that Top Story B, etc. If that is 
the case, a "priority" or "importance" ranking scheme can be used in 
conjunction with the atom:updated element.

<feed>
<entry>
<id>top-story-A</id>
<updated>2005-12-12T12:00:00Z</updated>
<i:rank scheme="priority">90</i:rank>
</entry>
<entry>
<id>top-story-B</id>
<updated>2005-12-12T12:00:00Z</updated>
<i:rank scheme="priority">80</i:rank>
</entry>
<entry>
<id>top-story-C</id>
<updated>2005-12-11T12:00:00Z</updated>
<i:rank scheme="priority">90</i:rank>
</entry>
<entry>
<id>top-story-D</id>
<updated>2005-12-11T12:00:00Z</updated>
<i:rank scheme="priority">80</i:rank>
</entry>
</feed>

In this example, top-story-A is ranked as the highest priority entry on 
Dec, 12, 2005 while top-story-C is ranked as the highest priority entry 
on Dec, 11, 2005.

Re: Eric's Question: "What happens when entries "fall off the bottom" 
... do their rankings expire?"

It will be entirely dependent on the scheme. In a priority ranking 
scheme (measuring the relative importance of an entry), having an entry 
"fall off the bottom" would have no effect on the overall 
ordering/ranking of the feed. In a natural order ranking scheme (indexed 
position), having an entry "fall off the bottom" would likely mean that 
the entry is no longer a part of the ordered list or is no longer 
relevant to the rankings.

Re: Thomas Broyer's suggestions:

 >1. get rid of your i:rank, users will use any extension element 
instead (no more
 > registry and you can still define "standard" priority and index 
extensions)

I considered this but a single extensible rank element fits most of the 
simple use cases for this rather well. That said, allowing for specific 
ranking elements would be helpful, so how about a bit of a compromise?

rankingCommonAttributes =
attribute i:scheme { IRI },
attribute i:domain { IRI }?

rankingConstruct =
rankingCommonAttributes

integerRank = element i:rank {
rankingConstruct (nonNegativeInteger)
}

With this approach, i:rank is defined as the standard nonNegativeInteger 
ranking element. If I so desired, I could easily define new 
rankingConstructs however, for instance:

importanceRank = element x:importance {
rankingConstruct ('critical' | 'high' | 'medium' | 'low' | 'info'|)
}

<x:importance i:scheme="importance" i:domain="urn:foo">high</x:importance>

 >2. get rid of your @order attribute: users should be able to choose in 
which
 >order they want their entries: best-ranked to least-ranked "top to 
bottom" or
 >"bottom to top". Its the responsibility of the producer to provide 
labels and
 >values that will be well-understood by users (e.g. not saying "stars" and
 >ranking from 1 (best rank) down to 5: "stars" implies "number of 
stars", so
 >"sort by stars in ascending order" implies "the highest the value, the 
better it
 >is", which is not what's behind 1=best-rank…)

Done.

 >4. (optional) add a data-type attribute to i:ranking (maybe rename 
that one to
 > something related to sorting, not ranking)
from using
 >QNames in attribute values, which doesn't work great with prefix changes)

I think I want to avoid this. Again, my goal is not to duplicate the 
function of the simple list extensions. In the same vein, I've removed 
the order attribute.

Ok, time for some use cases,

Imagine if Google wished to start offering search results in an Atom 
feed and that they wished to include Page Rank in with the results.

<feed>
<id>urn:my_google_search</id>
<i:domain>http://www.google.com</i:domain>
<entry>
<id>A</id>
<i:rank scheme="pagerank" domain="http://www.google.com">1234</i:rank>
</entry>
<entry>
<id>B</id>
<i:rank scheme="pagerank" domain="http://www.google.com">3456</i:rank>
</entry>
<entry>
<id>C</id>
<i:rank scheme="pagerank" domain="http://www.google.com">5467</i:rank>
</entry>
</feed>

<feed>
<id>urn:your_google_search</id>
<i:domain>http://www.google.com</i:domain>
<entry>
<id>A</id>
<i:rank scheme="pagerank" domain="http://www.google.com">1234</i:rank>
</entry>
<entry>
<id>D</id>
<i:rank scheme="pagerank" domain="http://www.google.com">785</i:rank>
</entry>
<entry>
<id>E</id>
<i:rank scheme="pagerank" domain="http://www.google.com">123</i:rank>
</entry>
</feed>

Note that the two feeds both specify pagerank values in the 
http://www.google.com ranking domain. If these feeds were aggregated 
together, a consumer could intelligently order the combined set of 
entries based on the i:rank pagerank values.

Another example, entries are ranked on a five-star scale

<feed>
<id>urn:my_reviews</id>
<i:domain>http://www.example.com/reviews</i:domain>
<i:domain>http://www.example.org/reviews</i:domain>
<entry>
<id>Movie A</id>
<i:rank scheme="fivestars" 
domain="http://www.example.com/reviews">3</i:rank>
<i:rank scheme="fivestars" 
domain="http://www.example.org/reviews">4</i:rank>
</entry>
<entry>
<id>Movie B</id>
<i:rank scheme="fivestars" 
domain="http://www.example.com/reviews">2</i:rank>
<i:rank scheme="fivestars" 
domain="http://www.example.org/reviews">1</i:rank>
</entry>
<entry>
<id>Movie C</id>
<i:rank scheme="fivestars" 
domain="http://www.example.com/reviews">5</i:rank>
<i:rank scheme="fivestars" 
domain="http://www.example.org/reviews">3</i:rank>
</entry>
</feed>

The feed specifies multiple ranking domains. To put this into a real 
world perspective, imagine that instead of domains 
http://www.example.com/reviews and http://www.example.org/reviews, it 
was http://www.netflix.com and http://www.amazon.com... e.g. Movie A is 
ranked with 3 stars on NetFlix.com and 4 stars on Amazon.com.

Anyway, that's what I have currently. Further thoughts?

- James

---

From: Antone Roundy <[email-masked]>
Date: Thu, 22 Sep 2005 09:03:21 -0600

> <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 feeds will be useful or not. In the 
movie ratings use case presented below, perhaps rather than a 
fivestarts scheme and netflix and amazon domains, it might make more 
sense to do this:

<feed>
<id>urn:my_reviews</id>
<i:order scheme="urn:netflix.com/reviews" label="Netflix 
rating">descending</i:order>
<i:order scheme="urn:amazon.com/reviews" label="Amazon 
rating">descending</i:order>
<entry>
<id>Movie A</id>
<i:rank scheme="urn:netflix.com/reviews">3</i:rank>
<i:rank scheme="urn:amazon.com/reviews">4</i:rank>
</entry>
<entry>
<id>Movie B</id>
<i:rank scheme="urn:netflix.com/reviews">2</i:rank>
<i:rank scheme="urn:amazon.com/reviews">1</i:rank>
</entry>
</feed>

Notes:
* The i:order element tells the user agent whether higher or lower 
numbers are considered "better", "higher priority", "first", or 
whatever. In these cases, higher numbers are better, so would 
typicially be shown first, so they're considered a "descending" schemes.
* i:order/@label indicates a human readable label for the scheme, and 
could be optional.
* Since the urn:(netflix|amazon).com/reviews schemes are feed 
independent, it is not necessary to indicate a feed (or "domain") in 
this case.
* For a feed-specific scheme, like natural order, the feed ID would be 
included like this (so that if these entries were aggregated, it would 
be clear that the i:order elements were relevant to the source feed, 
not the aggregate feed):

<feed>
<id>urn:my_feed</id>
<i:order scheme="urn:index">ascending</i:order>
<entry>
<id>urn:my_feed/a</id>
<i:rank scheme="urn:index" feed="urn:my_feed">1</i:rank>
</entry>
<entry>
<id>urn:my_feed/b</id>
<i:rank scheme="urn:index" feed="urn:my_feed">2</i:rank>
</entry>
</feed>

If sticking with i:domain, I'd recommend that you recommend that in 
cases where a ranking domain does not span multiple feeds, the feed/id 
value be used for the value of i:domain, and that in all cases, the 
same care be taken to (attempt to) ensure that i:domain's value is 
unique to what is intended to be a particular domain.

---

From: "James Holderness" <[email-masked]>
Date: Thu, 22 Sep 2005 16:02:31 +0100

James M Snell wrote:
> 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 sort of thing sounds like a good idea from a content 
provider's point of view, but as an aggregator developer, this is probably 
the last thing I would want to support. A feed that is not incremental is 
not a feed IMHO. There are just too many special case complications that an 
aggregator developer has to deal with that have nothing to do with regular, 
honest-to-goodness feeds.

Are you supposed to automatically delete old items? With or without the 
users' consent? Do you archive old items in some way? How do you handle the 
aggregation of items from multiple non-incremental feeds into a single feed? 
How do you handle the aggregation of items from multiple feeds some of which 
are incremental and some of which are complete datasets? How do you handle 
filtering that results in a subset of items from what is supposed to be a 
complete dataset?

That said, I suspect I'm fighting a losing battle, and I do like this 
proposal as it applies to ranking of feeds in general.

> aggregated into a synthetic feed that either a) does not specify a ranking 
> domain or b) specifies a different ranking domain, consumers can safely 
> ignore the urn:foo i:rank.

This kind of makes sense, but I'm not convinced it's necessary. If the feed 
has various ranks on which it can be sorted, I'd rather leave the decision 
on which one to use to the user. If, for whatever reason, those alternate 
domains are no longer applicable and the feed absolutely has to force the 
use of a particular domain, wouldn't it make more sense to filter out all 
those unused ranks rather than making the user download them?

> instance, two separate feed documents may specify the same ranking domain.

This I like.

> Top Story A has a higher importance that Top Story B, etc. If that is the 
> case, a "priority" or "importance" ranking scheme can be used in 

This almost works. As an aggregator, what I would want to do is 
automatically sort with the date as the primary key and the priority as the 
secondary key. That way, today's high-priority items would appear at the top 
of the list, and yesterday's would follow on afterwards. Any of yesterday's 
items that were still of some importance today would need to have their 
atom:updated element set to today and their priority adjusted as 
appropriate.

There are couple of problems though. The atom:updated element has to be 
identical for all items on a particular day. Also the atom:updated element 
can't be changed when an actual update occurs (say a spelling correction, or 
an update on a story) without breaking the ordering. The problem is we're 
abusing the atom:updated element so as to use it for something that's it's 
not.

It would be better if we could add an extra attribute to your rank tag that 
specified what date the rank applied to. For someone like the BBC that 
reprioritizes feeds on a daily basis they'd set this attribute to something 
like say midnight for the date on which the ranking applies. If you have an 
item from a previous day that is still important today, it would keep its 
original atom:updated value, but the rank-date would be set to today.

An aggregator supporting this extension could then sort on the rank-date as 
the primary key (descending) and the rank value itself as the secondary key. 
For feeds that don't change their priorities over time you can just leave 
this attribute out and the aggregator can sort on the rank value alone. I 
don't think it overly complicates the interface, but it does add significant 
value IMO.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Thu, 22 Sep 2005 08:50:09 -0700

James Holderness wrote:

>
> 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 sort of thing sounds like a good idea from a 
> content provider's point of view, but as an aggregator developer, this 
> is probably the last thing I would want to support. A feed that is not 
> incremental is not a feed IMHO. There are just too many special case 
> complications that an aggregator developer has to deal with that have 
> nothing to do with regular, honest-to-goodness feeds.
>
I do believe this falls under the Not-All-Feeds-Should-Be-Aggregated 
Category.  That said, however, I think the concept of Feed-As-List is 
one that generally has a lot of support.

> entry. For instance, if an entry with an i:rank in the urn:foo domain 
> is aggregated into a synthetic feed that either a) does not specify a 
> ranking domain or b) specifies a different ranking domain, consumers 
> can safely ignore the urn:foo i:rank.
>
> This kind of makes sense, but I'm not convinced it's necessary. If the 
> feed has various ranks on which it can be sorted, I'd rather leave the 
> decision on which one to use to the user. If, for whatever reason, 
> those alternate domains are no longer applicable and the feed 
> absolutely has to force the use of a particular domain, wouldn't it 
> make more sense to filter out all those unused ranks rather than 
> making the user download them?
>
i:domain is not used as a key of determining which rankings to use; it's 
a key that is used to correlate rankings.  Regarding filtering, we 
should not rely on aggregators filtering out unused ranks.  Consider the 
case of digitally signed entries; filtering out a rank covered by the 
digital signature would invalidate the signature.

>> 2. It helps us to correlate ranks that span multiple feed documents. 
>> For instance, two separate feed documents may specify the same 
>> ranking domain.
>
>
> This I like.
>
>> ranking of relative importance than a ranking of natural order. That 
>> is, Top Story A has a higher importance that Top Story B, etc. If 
>> that is the case, a "priority" or "importance" ranking scheme can be 
>> used in conjunction with the atom:updated element.
>
>
> automatically sort with the date as the primary key and the priority 
> as the secondary key. That way, today's high-priority items would 
> appear at the top of the list, and yesterday's would follow on 
> afterwards. Any of yesterday's items that were still of some 
> importance today would need to have their atom:updated element set to 
> today and their priority adjusted as appropriate.
>
> There are couple of problems though. The atom:updated element has to 
> be identical for all items on a particular day. Also the atom:updated 
> element can't be changed when an actual update occurs (say a spelling 
> correction, or an update on a story) without breaking the ordering. 
> The problem is we're abusing the atom:updated element so as to use it 
> for something that's it's not.
>
The updated elements would not need to be identical.  Aggregators can 
easily determine whether or not entries with different updated values 
occured on the same day / same hour / etc.  In other words, I could sort 
by Day+Priority, Hour+Priority, Minute+Priority, whatever, without any 
difficulty.  There is no abuse of atom:updated here.

> It would be better if we could add an extra attribute to your rank tag 
> that specified what date the rank applied to. For someone like the BBC 
> that reprioritizes feeds on a daily basis they'd set this attribute to 
> something like say midnight for the date on which the ranking applies. 
> If you have an item from a previous day that is still important today, 
> it would keep its original atom:updated value, but the rank-date would 
> be set to today.
>
I'll give this some thought, but my initial gut reaction is that it is 
not necessary.  Let me see if I can convince myself otherwise ;-)

> James
Thanks for the input!

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 22 Sep 2005 09:20:41 -0700

> fivestarts scheme and netflix and amazon domains, it might make more 
Using atom:id as the ranking domain would limit the ranking to a single 
feed which is useful, but does not cover the full range of cases.

> unique to what is intended to be a particular domain.
Yes, there are two special cases here:

1. Lack of a i:domain
2. i:domain value that is a same document reference

In the first case, I had imagined a "Default Ranking Domain" that is 
identified by the feed atom:id element, just as you suggest.
In the second case, I had imagined a "Document Ranking Domain" that is 
identified by the document containing the feed. 

There is a subtle difference between these two.  Consider the following 
(somewhat contrived) example:

  <xhtml:html>
    ...
    <xhtml:body>
      <atom:feed>
        <atom:id>Feed1</atom:id>
        <i:domain>#</i:domain> <!-- document ranking domain -->
        <atom:entry>
          <atom:id>A</atom:id>
          <i:rank scheme="priority">50</i:rank>
          <i:rank scheme="priority" domain="#">20</i:rank>
        </atom:entry>
        <atom:entry>
          <atom:id>B</atom:id>
          <i:rank scheme="priority">25</i:rank>
          <i:rank scheme="priority" domain="#">40</i:rank>
        </atom:entry>
      </atom:feed>
      <atom:feed>
        <atom:id>Feed2</atom:id>
        <i:domain>#</i:domain> <!-- document ranking domain -->
        <atom:entry>
          <atom:id>C</atom:id>
          <i:rank scheme="priority">50</i:rank>
          <i:rank scheme="priority" domain="#">30</i:rank>
        </atom:entry>
        <atom:entry>
          <atom:id>D</atom:id>
          <i:rank scheme="priority">25</i:rank>
          <i:rank scheme="priority" domain="#">10</i:rank>
        </atom:entry>
      </atom:feed>
    </xhtml:body>
  </xhtml:html>

The two embedded atom:feed elements specify two ranking domains: The 
Default Ranking Domain and a Document Ranking Domain.  The Default 
Ranking Domain is scoped to the individual atom:feed as is identified by 
the value of the atom:id.  the Document Ranking Domain is scoped to the 
containing document.

The Default Ranking Domain ranks may only be used to order the entries 
within the containing atom:feed: 
  sort_ascending ( Feed1 ) = B, A
  sort_ascending ( Feed2 ) = D, C

The Document Ranking Domain ranks may be used to order all entries 
appearing within the document
  sort_ascending ( Document ) = D, A, C, B

In an Atom Feed Document, the Default Ranking Domain and the Document 
Ranking Domain happen to be identical.

> typicially be shown first, so they're considered a "descending" schemes.

Hmm.. I wanted to get away from doing this kind of thing.

> be clear that the i:order elements were relevant to the source feed, 
The goal of @scheme is to identify the type of ranking to apply while 
the goal of @domain is to identify the scope of the ranking.  I do not 
believe that it is a good idea to conflate the two.

- James

---

From: Antone Roundy <[email-masked]>
Date: Thu, 22 Sep 2005 12:02:33 -0600

On Thursday, September 22, 2005, at 10:20  AM, James M Snell wrote:
>> 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. In the movie ratings use case presented below, perhaps rather 
>> than a fivestarts scheme and netflix and amazon domains, it might 
>> make more sense to do this:
>>
> Using atom:id as the ranking domain would limit the ranking to a 
> single feed which is useful, but does not cover the full range of 
> cases.
...
> 2. i:domain value that is a same document reference

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.

>          <i:rank scheme="priority" domain="#">10</i:rank>

In this example, the domainless rankings were added when the XHTML 
document was created, right?  So the XHTML document is essentially an 
aggregate feed, just not in Atom format.  Would it not make as much or 
more sense to mint an ID for the document (call it the ID of a "virtual 
Atom Feed Document" if you don't actually create an aggregate feed) and 
use it to scope those i:rank elements?  If, somehow, someone were to 
pull the atom:feeds out of the XHTML document (if atom:feed getting 
embedded into xhtml:body is going to happen, then is not atom:feed 
getting extracted from xhtml:body also likely?) and aggregate them with 
other feeds with domainless i:rank elements, the scopes of those 
elements would get mixed.

>> * For a feed-specific scheme, like natural order, the feed ID would 
>> be included like this (so that if these entries were aggregated, it 
>> would be clear that the i:order elements were relevant to the source 
>> feed, not the aggregate feed):
>>

Okay, I've come to agree with that while writing and editing this 
message.  Note however that "fivestar" also indicates multiple things:

1) Higher numbers are "better"
2) The range is 0 to 5 (BTW, if this is limited to integers, how will 
you handle things like 3.5 stars, which are common in that type of 
rating system? Maybe decimal values need to be allowed.)
3) Hint: you might want to display the value as stars

#1 is the only one needed for sorting of entries. #2 would be useful if 
the feed reader wanted to display some sort of graphical element to 
indicate the ranking. #3 might be slightly useful, but except for the 
most popular schemes, would probably be ignored. Perhaps all of these 
should be separated, a la:

<i:ranking-scheme
	label="Amazon rating"
	order="descending"
	min-value="0"
	max-value="5"
	symbol="stars"
	domain="urn:amazon.com/customer-rating"
/>
...
<entry>
<i:rank domain="url:amazon.com/customer-rating">3</i:rank>

...where @domain is the feed/id of the feed if there's just one feed in 
scope, or a value that won't be duplicated by any feed/id otherwise (if 
one can mint a unique feed id, surely one can also mint a unique id 
that won't be used for a feed).

I'd suggest that i:ranking-scheme/@domain either default to the 
containing feed/id (or the one from atom:source, if it exists) or be 
required, i:rank/@domain be required, @order default to ascending, 
@min-value default to 0, and the rest of the attributes be optional 
with no defaults.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Sep 2005 18:51:20 -0700

> slightly rewrite part of it.

Strictly read, this doesn't preclude other specifications /  
extensions from adding semantics to the ordering of entries -- it  
only says that *this* spec doesn't assign any meaning to it. That was  
the intent as I recall it.

> <fi:ordered /> element, even though this will have corrupted the data.

That is indeed a problem. Probably the easiest way to fix this would  
be in errata, by adding a statement like "Some feeds may implicitly  
or explicitly (through extensions) have meaning assigned to the  
ordering of entries, so intermediaries SHOULD NOT reorder them."

> without must-understand extensions, which Atom 1.0 doesn't support.

That would be another way to go, but people didn't want mU.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Sep 2005 18:56:23 -0700

> entries sorted by their natural order, with the time-ordered feed

There'd need to be an algorithm described for combing the feed  
documents; e.g., see the _combine() method in http://www.mnot.net/rss/ 
history/feed_history.py. In practice, most/all(?) popular aggregators  
do this now (feed history + natural order); the only change is that  
the algorithm would be documented and well-understood (which IMO  
would be a vast improvement, *if* we can agree on one... or more).

With the rank approach, you'd probably need to say that the ranks  
were valid within the scope of a single feed document, and then  
describe the relations between ranks in different feed documents. Not  
sure that's as interesting.

---

From: James M Snell <[email-masked]>
Date: Fri, 23 Sep 2005 12:01:12 -0700

> covered.  More on that below.
Agreed.

> more sense to mint an ID for the document (call it the ID of a 
> "virtual Atom Feed Document" if you don't actually create an aggregate 
> feed) and use it to scope those i:rank elements?  If, somehow, someone 
> were to pull the atom:feeds out of the XHTML document (if atom:feed 
> getting embedded into xhtml:body is going to happen, then is not 
> atom:feed getting extracted from xhtml:body also likely?) and 
> aggregate them with other feeds with domainless i:rank elements, the 
> scopes of those elements would get mixed.
>
Yes, but we cannot reliably dictate that containing documents must 
contain atom:id elements simply because we have no control over the 
definitions of those containing documents.  And yes, if someone pulls 
the feed out of the XHTML and uses it somewhere else, any ranks in the 
document scope will be affected.  I do not believe that this is a 
deal-breaker, however.. it's just something that folks using the ranking 
mechanism need to be aware of so that they can make the appropriate 
decisions about how and when to properly use the document ranking domain 
versus a domain that explicitly scoped to a given ID.

>> the goal of @domain is to identify the scope of the ranking.  I do 
>> not believe that it is a good idea to conflate the two.
>
>
> #1 is the only one needed for sorting of entries. #2 would be useful 
> if the feed reader wanted to display some sort of graphical element to 

Minutes before I received this note I had a similar thought that a 
scheme definition could be useful -- although that get's us quite close 
to the territory of the RSS simple list extensions (not that it is a bad 
thing).  The symbol attribute is a bit strange.  I'd rather let the 
application determine how it wants to display the rank.  The label, 
order, min and max values and domain attribute are fine.  And yes, 
regarding #2, allowing decimal values would likely be a good idea... 
doing so would also allow us to do ratings that are based on a 0-1 
fractional scheme (e.g. percentages, etc).  Negative values should also 
be allowed.

> ...where @domain is the feed/id of the feed if there's just one feed 
> in scope, or a value that won't be duplicated by any feed/id otherwise 
> (if one can mint a unique feed id, surely one can also mint a unique 
> id that won't be used for a feed).
>
I'm liking these suggestions...

The i:ranking-scheme element would appear within the atom:feed.  If the 
@domain attribute is missing, the domain is automatically mapped to the 
id of the feed. If the @domain attribute is a same document reference, 
the domain is mapped to the document scope.

  <!-- Ranking Domain is assumed to be equal to the feed's atom:id -->
  <i:ranking-scheme ... />

  <!-- Ranking Domain is scoped to the containing document -->
  <i:ranking-scheme ... domain="http://www.example.com" 
xml:base="http://www.example.com" />

The meaning of the @order attribute needs to be clearly articulated.  It 
is NOT an indicator of how applications should display the elements 
rather an indicator of how to interpret the rank values (e.g. highest 
number is most significant, lowest number is most significant).  With 
that in mind, I'm wondering if @order should be named something like 
"significance" instead. That is, for instance, if 
significance="descending", lower rank values have a lower significance 
that higher rank values.

  <feed>
    <i:ranking-scheme
      label="Five Stars" 
      significance="descending"
      min-value="0"
      max-value="5"
      domain="urn:amazon.com/customer-rating" />
    <entry>
      ...
      <i:rank domain="urn:amazon.com/customer-rating">5</i:rank>
    </entry>
    <entry>
      ...
      <i:rank domain="urn:amazon.com/customer-rating">3</i:rank>
    </entry>
  </feed>

Any given domain SHOULD only ever be associated with a single 
ranking-scheme. If more than one ranking-scheme is associated with the 
same domain, it is up to the application to select which of the schemes 
to apply while ignoring the others. 

If two feed documents specify conflicting ranking-schemes associated 
with a single domain, and an application wishes to combine the feeds and 
rank them as a single set, it is up to the application to figure out how 
to reconcile the conflict. 

If a ranking-scheme cannot be found for a given domain, the i:rank 
should be ignored.

The spec *could* (should?) provide a mechanism for registering 
ranking-schemes with IANA in order to allow feeds to use i:rank's with 
well known domains without having to include the ranking-scheme 
element.  The domain URI value of these registered ranking-schemes 
should be reflective of their IANA registration, for instance: 
"http://www.iana.org/assignments/rankings/generic-customer-rating"

  <i:ranking-scheme
    label="Importance"
    significance="descending"
    min-value="0"
    max-value="100"
    domain="http://www.iana.org/assignments/rankings/importance" />

  <feed>
    <entry>
      ...
      <i:rank 
domain="http://www.iana.org/assignments/rankings/importance">50</i:rank>
    </entry>
    <entry>
      ...
      <i:rank 
domain="http://www.iana.org/assignments/rankings/importance">30</i:rank>
    </entry>
  </feed>

Registering ranking-schemes in this way would help to mitigate the 
potential for conflicting ranking-scheme definitions across multiple 
feeds as it would provide a single, authoritative source for resolving 
the domain's ranking-scheme.

- James

---

From: "James Holderness" <[email-masked]>
Date: Wed, 28 Sep 2005 03:57:48 +0100

I'm sorry for the long delay in replying, but I've been swamped with work 
lately.

James M Snell wrote:
> i:domain is not used as a key of determining which rankings to use; it's a 
> key that is used to correlate rankings.

The correlating part I get - I think that's a great idea. It's part 1 
(quoted above) that I don't understand. You explicitly say a consumer can 
safely ignore the rank based on what domain it sees in a feed. How is that 
not a determination of which rankings to use?

> Regarding filtering, we should not rely on aggregators filtering out 
> unused ranks.  Consider the case of digitally signed entries; filtering 
> out a rank covered by the digital signature would invalidate the 
> signature.

I haven't been following the digital signature proposals, but I would have 
expected they would attempt to sign a particular content entry rather than 
trying to include all the metadata that went with it. Is it really safe to 
assume that an item aggregated into a synthetic feed or one that has passed 
through a caching/forwarding system will not have had metadata tags added, 
removed or reordered? I guess this is offtopic though and I see your point.

>> identical for all items on a particular day. Also the atom:updated 
>> correction, or an update on a story) without breaking the ordering. The 
>> problem is we're abusing the atom:updated element so as to use it for 
>> something that's it's not.
>>

The problem is knowing what to sort on. Unless you provide that information 
somewhere in the feed there's no way for the aggregator to perform the sort 
automatically. Say BBC updates its ranks every 6 hours, how is the 
aggregator to know that it should sort by halfday+priority? Or maybe it 
updates at 8am and 2pm every day - how would an aggregator deal with that?

With my proposal they would set rank-date to 8am (of the current day) for 
every item updated between 8am and 2pm. And items updated from 2pm to 8am 
the following day would have a rank-date of 2pm. The aggregator sorts on 
rankdate+priority and it all just lines up automatically. No guessing 
required.

> I'll give this some thought, but my initial gut reaction is that it is not 
> necessary.  Let me see if I can convince myself otherwise ;-)

You could be right. It's not exactly a critical need. I just thought it 
wouldn't harm at least having it there as an option for those people that 
might want that level of control.

Regards
James