On 1/5/06 5:55 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> 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. I just reviewed the relevant example in the APP spec and it's worrisome. Reading between the lines it suggests that the subscription uri is "http://example.org/entries/go";, with the rest of the collection available via rel="next" through to "http://example.org/entries/10";. The worrisome thing is that once that collection gains another 10 entries, then the resource "http://example.org/entries/11"; will now contain the entries which were previously contained by resource "http://example.org/entries/10";. Every page of the collection needs to be updated and have the entries shuffled along. A simplified example: /entries/go contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D which then gets another 4 entries added (ie. U,V,W,X) and the collection now looks like this: /entries/go contains entries U,V,W,X /entries/1 contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D This is just smells bad in so many ways. Pity the blog package that publishes static files and will have to rebuild every collection page. Pity the poor server that gets asked if /entries/3 has been modified and if so hand it over. Pity the google bot that does all that asking. Of course, this sentence doesn't parse into English real well either: "next" and "prev" link elements reference the preceding and subsequent feed documents in the set. ie. "next" references the *preceding* feed document, and "prev" references the *subsequent* feed document. It doesn't even make sense when read Down Under ;-) e.
