Re: Tools that make use of previous/next/first/last links?
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. 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. e.
Re: Tools that make use of previous/next/first/last links?
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
Re: Tools that make use of previous/next/first/last links?
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.
Re: Tools that make use of previous/next/first/last links?
Mark Nottingham [EMAIL PROTECTED] wrote: One thing I did notice -- you're using URLs like this for your archives: http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? page=2amp;count=10 Are they really permanent? If they're relative to the current state of the feed (i.e., the above URI means give me the ten latest entries), you can get into some inconsistent states; e.g., if somebody adds/deletes an entry between when the client fetches the different archives. Also, if a client doesn't visit for a long time, it will see http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? page=2amp;count=10 and assume it already has all of the entries in it, because it's fetched that URI before. This is the biggest issue I have with the history spec as written. I have urls like that, which aren't 'archive documents' as defined. That means I can't implement the history spec even though I have conventional chronologically ordered feeds with link rel=prev/next elements where old entries are available. I believe that by being more precise about exactly what is needed by the client to implement feed history usefully you can significantly relax the requirements. I believe the algorithm can be written so that clients can use history with a feed like mine. Regards, Peter
Re: Tools that make use of previous/next/first/last links?
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. Yes it does. (Though as was later clarified it's not that OpenSearch specifies any chronological ordering as such, but it is true that anyone who wants to implement OpenSearch in a conventional time-ordered feed will have to have next pointing back in time.) I thought it was agreed when we were discussing registering the link relations for prev/next etc. that the registration would not specify whether next meant backwards or forwards in time, but that specs making use of them would be written to be 'sign independent'. E.g. the history spec (or something else) would define an element nextIsBackwardsInTime value=yes / or whatever, that publishers could set and consumers would be required to check. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/ Concerts, sport and theatre tickets
Re: Tools that make use of previous/next/first/last links?
Yes, the paging in APP is a problem (one I've been largely ignoring up to this point in our own implementation). There is no way of reliably and efficiently reconstructing the entire feed history. - James Eric Scheid wrote: 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.
Re: Tools that make use of previous/next/first/last links?
Mark, Right now, the subscription feed uses previous to point to the archive feeds. Perhaps a better approach would be to to have an archive link relation that points to the first of a distinct set of archive feeds. Also, remove the temporal semantics from the the previous link and require that each archive page contain the entries from a fixed period of time (that is, each archive feed document is complete within a given time period) !-- Subscription feed -- feed ... link rel=self href=/feed.xml / link rel=archive href=/2006/04/feed.xml / /feed !-- /2006/04/feed.xml -- feed ... link rel=self href=/2006/04/feed.xml / link rel=current href=/feed.xml / link rel=next href=/2006/03/feed.xml / link rel=first href=/2006/04/feed.xml / link rel=last href=/2006/01/feed.xml / /feed !-- /2006/03/feed.xml -- feed ... link rel=self href=/2006/04/feed.xml / link rel=current href=/feed.xml / link rel=previous href=/2006/04/feed.xml / link rel=next href=/2006/02/feed.xml / link rel=first href=/2006/04/feed.xml / link rel=last href=/2006/01/feed.xml / /feed This completely removes the current subscription feed from the history reconstruction and eliminates the sliding window effect. Reconstructing the feed history becomes a simple matter of locating the archive link and iterating over a set of fixed pages. - James Mark Nottingham wrote: Did you find that algorithm wrong, too hard to understand/implement, or did you just do a different take on it? Does the approach that you took end up having the same result? Any suggestions on how to better document it appreciated. Cheers, On 2006/04/26, at 8:35 PM, James Holderness wrote: We added support for next/prev/previous links in version 0.3.0 of Snarfer [1]. We don't use the reconstruction algorithm suggested in the Feed History draft, but your example feed seems to work ok for an initial retrieval. There may be problems with subsequent updates, though, depending on how you handle items falling out the bottom of the main feed. Regards James [1] http://www.snarfware.com/ John Panzer wrote: We just deployed support for [EMAIL PROTECTED]previous et al. for AOL Journals. If anyone has a client that makes use of these links, please let me know, I'd love to see if there are any interoperability problems. -- Mark Nottingham http://www.mnot.net/
Entry types
Looking at Google's gdata and IBM's open activities APP implementation as examples, there appears to be a solid use case for defining a common categorization scheme for associating a type label to an entry. For instance, Gdata defines the following: atom:category scheme=http://schemas.google.com/g/2005#kind; term=http://schemas.google.com/g/2005#contact/ Our stuff uses: atom:category scheme=http://ibm.com/oa/type; term=task / I'm wondering if it would make sense to have a single common type scheme that could be used consistently across implementations. atom:category scheme=http://www.w3.org/2005/Atom/Entry-Kind; term=http://schemas.google.com/g/2005#contact; label=Contact / atom:category scheme=http://www.w3.org/2005/Atom/Entry-Kind; term=http://ibm.com/oa/type#task; label=Task / The category could be used on Feeds and Entries. Thoughts? - James
Re: Tools that make use of previous/next/first/last links?
James M Snell wrote: Right now, the subscription feed uses previous to point to the archive feeds. Perhaps a better approach would be to to have an archive link relation that points to the first of a distinct set of archive feeds. If I have to add yet another algorithm for paging support in addition to the ones that are already there, I'd be inclined to just dump the whole thing. Yes, the paging in APP is a problem (one I've been largely ignoring up to this point in our own implementation). There is no way of reliably and efficiently reconstructing the entire feed history. I would have thought a combination of RFC3229/feed with paging would be adequate. Something like that should work perfectly well with any client that already supports those features. It doesn't require the invention of a whole new system. Regards James
Atom Rank Extensions
All, A new draft of the Feed Rank extension has been published. Andreas Sewe has joined on as an author and has contributed significantly to this rev of the draft. There are many updates to the extension that are worth highlighting. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-09.txt First, the purpose of this extension is to provide a flexible means of ranking entries within a feed. For instance, a feed might represent an ordered listing of items from a movie rental queue; or each entry in a feed might contain a five star review ranking; or each entry in the feed might represent a listing of a students graded homework assignment, where each rank represents the grade assigned to the work, etc. For example, when combined with Mark Nottingham's Feed History extension for marking a feed as complete, Feed Rank provides a good solution for representing a movie rental queue: feed xmlns=http://www.w3.org/2005/Atom; xmlns:r=http://purl.org/syndication/rank/1.0; idtag:example.org,2006:my_movie_queue/id fh:complete xmlns:fh=http://purl.org/syndication/history/1.0/ title type=textMy Movie Queue/title updated2006-05-01T12:00:00Z/updated authornameJames/name/author link rel=self href=queue.xml / link href=queue.html / r:scheme name=tag:example.org,2006:my_movie_queue label=Queue Position significance=descending r:range minimum=0 step=1 / /r:scheme r:scheme name=tag:example.org,2006:movie_reviews label=Customer Reviews signifiance=ascending r:range minimum=0.0 maximum=5.0 step=0.5 scale=1 / /r:scheme entry idtag:example.org,2006:movies/chaplin/citylights/id title type=textCity Lights/title updated2006-05-01T12:00:00Z/updated link href=/movies/chaplin/citylights.html / summaryCharlie Chaplin's cassic film/summary r:rank domain= scheme=tag:example.org,2006:my_movie_queue1/r:rank r:rank domain=tag:example.org,2006:movie_reviews scheme=tag:example.org,2006:movie_reviews4.5/r:rank /entry entry idtag:example.org,2006:movies/chaplin/moderntimes/id title type=textModern Times/title updated2006-05-01T12:00:00Z/updated link href=/movies/chaplin/moderntimes.html / summaryAnother Chaplin classic/summary r:rank domain= scheme=tag:example.org,2006:my_movie_queue3/r:rank r:rank domain=tag:example.org,2006:movie_reviews scheme=tag:example.org,2006:movie_reviews3.5/r:rank /entry entry idtag:example.org,2006:movies/chaplin/thegoldrush/id title type=textThe Gold Rush/title updated2006-05-01T12:00:00Z/updated link href=/movies/chaplin/thegoldrush.html / summaryChaplin in a frozen wilderness/summary r:rank domain= scheme=tag:example.org,2006:my_movie_queue2/r:rank r:rank domain=tag:example.org,2006:movie_reviews scheme=tag:example.org,2006:movie_reviews5.0/r:rank /entry /feed While there are a variety of changes throughout the entire spec, the key differences in this draft lie in the definition of the Ranking Schemes. A Ranking Scheme is now defined as a set of discreet values and/or ranges. For instance, a typical U.S. grading scheme can be represented using a series of ranges representing percentage values: r:scheme name=tag:example.org,2006:grades label=Percentage Grading System significance=ascending r:range label=F minimum=0.00 maximum=0.59 scale=2 step=0.01 / r:range label=D minimum=0.60 maximum=0.69 scale=2 step=0.01 / r:range label=C minimum=0.70 maximum=0.79 scale=2 step=0.01 / r:range label=B minimum=0.80 maximum=0.89 scale=2 step=0.01 / r:range label=A minimum=0.90 maximum=0.99 scale=2 step=0.01 / r:value label=A+ scale=21.00/r:value /r:scheme In contrast, the typical German grading scheme can be represented as a set of discreet values: r:scheme name=tag:example.org,2006:grades label=Grading System significance=descending r:value label=1 scale=11.0/r:value r:value label=1- scale=11.3/r:value r:value label=2+ scale=11.7/r:value r:value label=2 scale=12.0/r:value r:value label=2- scale=12.3/r:value r:value label=3+ scale=12.7/r:value r:value label=3 scale=13.0/r:value
Re: Atom Rank Extensions
* Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]: especially when changes requested by the community are met with hostility and channel flooding. Did this happen in more cases than the one I’m aware of? You know, the one where James eventually caved on both distinct points anyway? When I read terms like more standard wrt the feed thread extension, it makes me cringe. There are obvious reasons why that one is better than the rag-tag group of RSS extensions required to duplicate even a limited set of its use cases. We’ve had that discussion in other venues. (If you do require a blow-by-blow posted here, I can put together a summary for the WG.) By my count, James has 11 drafts in the system, all Atom-related. Many of them are copies of existing RSS extensions. It doesn't seem appropriate to issue competing versions of various extensions from Microsoft, Yahoo et al. and claim they are products of community consensus, Granted, but don’t lump them all together. Some of them *are* products of community consensus; the Thread extension in particular got a lot of churn (more than the others by a wide margin; ~250 posts on this list by my last count, aside from a dozen weblog threads or so). At least one or two others received some attention as well (the Licence extension I think? I didn’t pay much attention to those). It appears that it would be most productive if you simply express any specific concerns you have about particular drafts and their overlap with particular RSS extensions, instead of going for an ad hominem against James. It worked for David Powell; his concerns about technical flaws in the Thread extension convinced James to revise the draft, where your vociferous unsubstantiated objections had previously failed. In any case I’m puzzled why you’d start ringing alarm bells just now. None of these I-Ds are new; they’re all at least several months old and some have been through a half-dozen revisions and corresponding announcements. How did they escape your notice for so long? If they did not, why have they only become a problem now? for that excludes the IETF from defining the problem. How do you mean? (Question to be taken at face value. I honestly am not sure what you mean here.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Atom Rank Extensions
On 5/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]: especially when changes requested by the community are met with hostility and channel flooding. Did this happen in more cases than the one I'm aware of? Yes. When I read terms like more standard wrt the feed thread extension, it makes me cringe. There are obvious reasons why that one is better than the rag-tag group of RSS extensions... Disagree. There is no proof of that. It appears that it would be most productive if you simply express any specific concerns you have about particular drafts and their overlap with particular RSS extensions, instead of going for an ad hominem against James. I didn't go for an ad hominem. That would be something like the feed draft is bad because James wrote it. I disagree with many decisions in the draft, but that is because I think they are misguided, not because I dislike the person who wrote them. For instance, every other threading extension uses a simple element with a number to represent the number of responses. This is limited in theory, but in practice, such elements are so easy to deploy, they prove valuable. In fact, a few WG members used my unauthorized version of the feed thread extension to track my comments. It worked for David Powell; his concerns about technical flaws in the Thread extension convinced James to revise the draft, where your vociferous unsubstantiated objections had previously failed. Nonsense. Sylvain pointed out that he was being pushy and ignorant, and only then did he changed it. I think you're confusing James' rhetoric with reality. A silly mistake. His rhetoric is pretty clumsy. In any case I'm puzzled why you'd start ringing alarm bells just now. I-Ds by themselves are not an issue.Of course, actual change control is, and documents pushed through the process without problem-definition in the IETF are much more prone to abuse. It really does bother me that these documents are being pushed through at the same level as the Atom draft itself, and I don't think I need to apologize for my timing. Anyway, I don't see how the timing of my email is not relevant to the topic at hand. Besides, I was b-b-b-banned during lots of it, but I've getting better at being courteous to the ethically-challenged. for that excludes the IETF from defining the problem. How do you mean? (Question to be taken at face value. I honestly am not sure what you mean here.) Defining the charter, etc, etc. It's a good thing to do. Are there any WG members left who were around at that phase? I joined right around then... -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Feed thread update
A. Pagaltzis wrote: It worked for David Powell; his concerns about technical flaws in the Thread extension convinced James to revise the draft, where your vociferous unsubstantiated objections had previously failed. Speaking of which, I'm not very happy about it, but I just sent off an updated version of the Feed thread draft for publication that does away with the thr;count and thr:when attributes on the link and introduces a thr:replies element. The example below appears within the updated draft, feed xmlns=http://www.w3.org/2005/Atom; xmlns:thr=http://purl.org/syndication/thread/1.0; idtag:example.org,2006/id titleEntries and Comments/title ... entry idtag:example.org,2006:1/id titleMy Post/title updated2006-05-01T08:08:08Z/updated link rel=replies href=/comments type=application/atom+xml / thr:replies ref=tag:example.org,2006:comments label=Comments and Trackbacks count=2 updated=2006-05-01T12:12:12Z/ thr:replies ref=tag:example.org,2006 label=Follow-ups and Corrections count=1 updated=2006-05-01T09:09:09Z / ... /entry entry idtag:example.org,2006:2/id titleMy Second Post/title updated2006-05-01T09:09:09Z/updated link rel=replies href=/comments type=application/atom+xml / thr:replies ref=tag:example.org,2006:comments label=Comments and Trackbacks count=1 updated=2006-05-01T10:10:10Z / thr:in-reply-to ref=tag:example.org,2006:1 / ... /entry /feed As you can see from the example, the thr:replies/@ref attribute points to an atom:id value, and not the URI used by the link. When going through and trying to implement the original concept with href, the xml:base issues proved to be more hassle than it was worth. Look for the updated draft to publish in the next day or so. - James
