Subject: PaceElementOrder

From: Antone Roundy <[email-masked]>
Date: Fri, 9 Jul 2004 10:18:46 -0600

> Ordering of the atom:entry element children of atom:feed element MUST 
> NOT be considered significant.
As we all know, there is a common convention to order RSS items and 
Atom entries in reverse chronological order.  While I'm CERTAINLY in 
favor of not requiring this, this wording seems to me to frown on that 
convention--not for the generator, which can order things however it 
wants, but to frown on client software which renders the entries in the 
order they appear in the feed.  If we were to add language suggesting 
that generators MAY order the entries in the order they suggest they be 
rendered, or if we were to add an OPTIONAL capability for indicating 
the recommended ordering (I'm not a fan of RSS 1.0 partly because it 
requires the sequence list...I for one would go with ordering the 
entries in a suggested presentation order over this), there would be 
some value in that.

One could say that the date elements are sufficient to indicate 
ordering, but there are a few problems with that idea:

1) Chronological order may not always make sense.
2) Which of the Date Constructs should be used?
3) Stream-based processors which output the entries as they process 
them would have to build in provisions for reordering, which could be 
overly burdensome in some circumstances (memory requirements for large 
feeds on devices with little memory, etc.)  This is also an argument 
against adding a capability for suggesting ordering separate from the 
actual order of the entries themselves.

All that said, I'm not TOO worried about this, but thought I'd throw 
these ideas out there.

Antone