The most reliable approach here would be to create an extension that allows the appropriate order to be recreated. The index extension I had pitched a while back took this approach. It's most effective if the feed publisher ensures that the entries are presented in the proper order, but even if they are not, the client can faithfully recreate the appropriate ordering.
- James A. Pagaltzis wrote: > * David Powell <[EMAIL PROTECTED]> [2007-05-24 02:05]: >> Wednesday, May 23, 2007, 9:11:09 PM, A. Pagaltzis wrote: >>> A client could then use this optional information, where it >>> is present, in order to optimise its processing. >>> RFC 4287 itself makes no such provision, though. >> ... and there is no guarantee that such an extension would >> work, because by overriding RFC4287s assertion that a feed is >> unordered, the extension would effectively have mustUnderstand >> semantics, which Atom doesn't support. > > How so? Pure RFC 4287 implementations would process the entire > feed as usual. Clients which understand the extension could skip > some of the processing based on the order of the entries. I see > no change in feed semantics that would affect oblivious clients. > >> Having said that, Microsoft's Simple List Extensions for RSS >> [1] might be useful. They allow you to specify a sort order for >> display of a feed, and the default sort order additionally acts >> as an assertion that the feed is physically sorted in that >> order. The caveats above still apply though. >> >> [1] http://msdn2.microsoft.com/en-gb/xml/bb190612.aspx > > FWIW, the `cf:treatAs/text()='list'` feature of that spec *does* > change the feed semantics in a way incompatible with RFC 4287. > > The `cf:listinfo` feature set OTOH would be what Matthew Becker > is looking for, and can be used independently of the `cf:treatAs` > feature, and if it is, then by the aforementioned argument, the > caveat does *not* apply. > > Regards,
