On 8/30/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > No. I'm saying that if Netflix switches over to Atom, what they > should do is insert the Queue information, as a list, into a single entry > within the feed.
Correct me if I'm wrong, but doesn't Atom already support this, along with pretty much every other approach? Entries in an individual feed document are unordered. The client can derive a well-defined order from the dates (or have something considerably less controlled going per doc changes). That's for date order. But the client could sort entries according to some other derived order - e.g. alphabetically by title or content or by size. Or by value of the x:priority element on each entry, with perhaps a later entry flagged <x:priority>2</x:priority> replacing the current entry with an element with that value. Or by interpretation of something like: <atom:entry> ... <atom:content xmlns="http://www.w3.org/1999/xhtml"; ...> <ol class="chart order"> <li><a href="tag:.stuff.entryx">Number One</a></li> <li><a href="tag:.stuff.entryy">Number Two</a></li> ... </ol> </atom:content> ... </atom:entry> ( - is that the kind of thing you had in mind, Bob?) Another alternative would be: <atom:entry> ... <atom:content>whatever</atom:content> ... <x:sortOrder title="chart order"> <x:sortItem uri="tag:.stuff.entryx" /> <x:sortItem uri="tag:.stuff.entryy" /> </x:sortOrder> ... </atom:entry> i.e. having the list order provided in a single entry, but through extensions rather than in the content. There's a load of other alternatives to - adding "next" and "previous" URI links, labelled with whatever axis the sort order is over. I doubt there's much difference in terms of effort needed to support either the per-entry or in-entry approaches. Capabilities of the client might make a lot of difference though - expressing the order in XHTML might be more client-friendly than using something like RDF/XML or any other hard-to-view format. With the aggregator code I've been playing with recently the list approach might be marginally easier to support, as it could be XSLT'd across to an rdf:List. Sorting on an x:sortPosition kind of element could be trickier as that would need to be considered in combination with the date, but then again joins may be more flexible. Cheers, Danny. -- http://dannyayers.com
