Eric Scheid wrote: > On 1/5/06 2:25 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > >> While I'm sure the other James may have his own particular set of >> issues, the one pain point for me with the history spec is the use of >> the "previous" link to point back in time. This runs counter to the use >> of the previous link in both OpenSearch, APP and Gdata. > > I thought OpenSearch results are not sorted by chronological age at all, but > instead by relevance? Using "next" with OpenSearch makes sense in that > context. Using "previous" for stepping back thru time in a data store > arranged chronologically makes sense. >
My apologies, I did not mean to imply that OS used chronological ordering. Quite the opposite, in fact; that is, opensearch defines no meaning to the ordering of pages at all. Previous just means the previous page in a set. > I'm not familiar with how Gdata arranges it's data, but briefly scanning the > API docs it's modelled on OpenSearch, and furthermore it says "Result > ordering is up to the implementation" ... thus I would think it would be > right for it to use 'next' to get the next page, but wrong to assume that > this would imply stepping backwards chronologically. > I'm generally against making any assumptions about whether or not next/previous points to anything but some other page of entries; if you want to know whether they're newer or older, just look at the updated timestamp and sort accordingly. That said, however, we end up with a problem when we have one spec that says next points backwards in time (APP), one spec that says next points forwards in time (feed history) and one spec that says next is just another page of entries that match some criteria (opensearch). No matter what the various link types point to, there needs to be consistency. As it stands now, a single feed cannot implement APP, OpenSearch AND Feed History. - James
