Re: Tools that make use of previous/next/first/last links?
Mark Nottingham [EMAIL PROTECTED] wrote: Can you expand upon being more precise about exactly what is needed? I don't have time to go into very much detail right now, but basically it's about what people are calling 'stable urls' in another part of this thread. The draft calls feeds where it's sensible to maintain a history 'incremental feeds', but defines an incremental feed as a 'subscription document' plus a series of 'archive documents'. An archive document is defined as a feed (url) whose entry set doesn't change. It was necessary for you to require 'archive documents' with fixed element sets because your history reconstruction algorithm's state is stored as feed urls. If you rework the algorithm so its state is stored in terms of atom:ids or guids then you no longer require archive documents to have fixed entry sets (and they probably shouldn't be called archive documents in that case). I need to write down a concrete algorithm that remembers atom:ids instead of feed urls, but I believe that is perfectly possible (without any particular extra burden on the client) if you have these two requirements (which need more formal wording): - new entries can only be inserted at the start of the 'logical feed' - old entries can only be deleted at the end of the 'logical feed' (you can weaken these to make no requirement of the order within a single feed document's xml as long as the 'real' order is preserved on the server) The simplest way to satisfy those two requirements is to have a conventional feed where the entries are ordered by publication date and none are ever removed. For a feed that satisfies those requirements whose pages are all 'sliding windows' it's not possible to miss any entries if you traverse the next/prev links in the right direction. Regards, Peter
Re: Tools that make use of previous/next/first/last links?
Mark Nottingham [EMAIL PROTECTED] wrote: On 2006/05/01, at 12:55 AM, James M Snell wrote: As it stands now, a single feed cannot implement APP, OpenSearch AND Feed History. Please describe the scenario where you'd want that to happen -- show the feed. I don't use APP, but this feed implements OpenSearch and would like to allow clients to maintain a history: http://www.ticketswitch.com/cgi-bin/atom_feed.exe The OpenSearch description is here: http://www.ticketswitch.com/cgi-bin/rss_open_search_desc.exe (The name is a holdover from when OpenSearch was rss-only.) Regards, Peter
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: New Link Relations -- Last Call
Hi Mark, Mark Nottingham [EMAIL PROTECTED] wrote: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. I can. The argument as I understand it is that relations should be nouns rather than verbs (describing what the link points to rather than what you should do with it). I can't argue that point, but I do feel that 'current' less encapsulates the intent than 'subscribe'. Someone else suggested 'subscription'. This should be my last word on the subject: Apparently it came as a surpise to some that rel='self' as defined is not the same as 'the url you should subscribe to' in the general case. I don't want to make the same mistake yet again. First example: consider a statically archived non-incremental OpenSearch-style feed split into pages: http://www.example.com/feed/2001/page3 A reasonable interpretation (the only possible interpretation?) of rel='current' would be this: http://www.example.com/feed/current/page3 which is certainly not the url you should subscribe to. Second example: a dynamic feed where cgi variables are used to set options, perhaps for use in building an html page of links rather than normal subscription, but you can come up with other uses: http://www.example.com/feed?year=2001no_atomcontent=yes Rel='current' would point to http://www.example.com/feed?no_atomcontent=yes but it would be much better for PubSub or a desktop aggregator to go to http://www.example.com/feed if it ever got hold of such a feed. The second example is (essentially) something I already do. I don't expect urls like that to 'escape' into the wild, but I can't prevent it and I'd like to be able to give an aggregator something meaningful to do when it does happen. If we want to define a link relation meaning 'the url you should subscribe to' then that is what we should define. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? I don't think that is any better. I am also worried that this is being pushed through too quickly. I appreciate that, but it's a bit of a chicken-and-egg problem; we won't get all of the implementation experience until it's defined and widely deployed. That is true, but have you communicated with the OpenSearch people about this? I do strongly believe that *here* is the place for work like this, rather than behind closed doors at Amazon. But if I was them I'd feel pretty miffed that this WG appears to have basically stolen their idea in a desperate 'land grab', and turned it on its head so that it is (arguably) the complete opposite of their intended definition. [snips] OpenSearch uses 'next' to go from page=1 to page=2. The natural paging setup for an inremental feed that is also an OpenSearch results feed is to have rel=current (aka rel=subscribe) point to the first page of results (i.e. page=1). Is it the intention that history reconstruction uses 'next' links to go back into the past? [...] Right now, the plan forward seems to be that 'next' et al will be purposefully generic; i.e., they won't mean much until used in conjunction with another extension (in my case, fh:incremental). My plan for feed history is to recommend people walk both 'previous' and 'next' from the subscription feed, so that it doesn't matter which way the feed goes. I see! That little nugget of an idea makes me feel a lot more comfortable about prev/next. So something that understands rel=previous, next et al will be able to reconstruct a complete logical feed, and the history extension will tell it 'which way is up' and whether it's a traditional 'incremental' feed. That makes a lot of sense. Regards, Peter
Re: New Link Relations -- Ready to go?
Having not spoken up so far, I'd like add my 2c. My atom feeds are all dynamic OpenSearch-style search results. By default they also happen to be traditional 'incremental' blog-style feeds. Instead of static archives, I have dynamic page=N sliding windows. I'd like to be able to include machine-interpretable 'prev'/'next' links so that a user agent that wants to can reconstruct a complete (logical) feed whether that means a 'history' or just the current snapshot of results (and at a single instant in time it will get the same set of entries in either case). I'd also like to be able to include a machine-interpretable rel=subscribe link since in general the url I have to put in rel=self is not the optimal link for subscription. Mark Nottingham [EMAIL PROTECTED] wrote: - Attribute Value: previous - Attribute Value: next - Attribute Value: first - Attribute Value: last With regret I am -1 to those since I cannot use them consistently (with those definitions) from 'page 1' of my feeds depending whether I have my OpenSearch hat on or my incremental feed hat. I need a 'pure paging' definition of those relations that can also be used to reconstruct feed history as a side-effect in the special case where my feeds happen to be 'incremental'. - Attribute Value: subscribe - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. +1 I am happy with that wording, though it may have been improved later in the thread. Whatever may have been the original intention, the Atom spec is very clear that rel=self is very different from any possible rel=subscribe. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/ Concerts, sport and theatre tickets
Re: New Link Relations -- Last Call
Mark Nottingham [EMAIL PROTECTED] wrote: I've replaced subscribe with current; otherwise, these are the same as in the last round. I think they're ready to go -- any more comments? I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. I am also worried that this is being pushed through too quickly. - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. - Attribute Value: next - Attribute Value: first - Attribute Value: last - Description: [consequent descriptions] OpenSearch uses 'next' to go from page=1 to page=2. The natural paging setup for an inremental feed that is also an OpenSearch results feed is to have rel=current (aka rel=subscribe) point to the first page of results (i.e. page=1). Is it the intention that history reconstruction uses 'next' links to go back into the past? If so I think that must be made much more explicit in the descriptions, since it is not the natural interpretation if you come at this purely from the standpoint of blog history. On the other hand, if that is *not* the intention then paging for history and paging for OpenSearch will be incompatible. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/ Concerts, sport and theatre tickets
Re: Feed History -04
James Holderness [EMAIL PROTECTED] wrote: [About feed history and atom:link vs. fh:prev] I'm surprised nobody else has commented though. To me this seems like one of the most important extensions to Atom/RSS, and yet there aren't exactly hordes of people rushing to implement it or at least committing to do something once it's officially released. Or have I just missed previous discussions on the subject? As a feed producer, I would love for feed consumers to be able to pull back the history of my feeds if they choose. But unfortunately seeing the way this discussion is going, and the (for me) closely related ordering extension, I'm not convinced I will be able to use them. Of couse if you don't turn up, you don't get to complain about decisions that get made, and unfortunately I don't have as much time as I'd like to participate in these discusions. But it's not that I don't care. As far as the question at hand, I would be able to implent it in my Atom/RSS2 feed generator easily enough either way. Obviously it will be a small amount of extra work if there is a format-dependent difference. Playing devil's advocate for a minute, is it very wrong to use atom:link for feed history in *RSS2*? Regards, Peter -- Peter Robinson http://www.ticketswitch.com/
Re: geolocation in atom:author?
Peter Robinson [EMAIL PROTECTED] wrote: I do something similar, intending it to mean the location of the items described by this feed (when there is a single location). http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=53.82:-3.05:10 To the person looking for items near Park Avenue 38th, New York. The third bit of s_geo is a radius (in km) and it's required. Try this: http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=40.75:-73.98:10 Regards, Big Brother
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Bob Wyman [EMAIL PROTECTED] wrote: Paul Hoffman asked: Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition I believe the correct answer is e: e) Unless otherwise specified, this information pertains to the feed only. I agree. Once you've accepted that there's a difference between the feed itself and the set of all past, present and future articles in the feed (which there certainly is in the general case) then you really have to accept e) as the only possibility for unknown metadata in the feed head section. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/
Re: geolocation in atom:author?
Paul Hoffman [EMAIL PROTECTED] wrote: At 12:17 AM +1000 8/22/05, Eric Scheid wrote: In this example, can anything intelligent be said about the various different locations? Is my intent clear, or are there clear ambiguities? feed ... ... geo:coordslocation#1/geo:coords author namefoo/name geo:coordslocation#2/geo:coords /author entry author namefoo/name geo:coordslocation#3/geo:coords /author geo:coordslocation#4/geo:coords content.../content ... /entry /feed #2 through #4 seem understandable, but what the heck is #1? The place where this feed was put together? The place where this feed was originally grabbed from? I do something similar, intending it to mean the location of the items described by this feed (when there is a single location). I don't know whether any software understands my intent... http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=53.82:-3.05:10 Regards, Peter -- Peter Robinson http://www.ticketswitch.com/
Re: OpenSearch and Atom Prototype
James M Snell [EMAIL PROTECTED] wrote: FYI... wanted to experiment a bit. OpenSearch+Atom http://www.snellspace.com/wp/wp-opensearch.php?s=OpenSearch When I updated my feed generator to support atom[1], I just added the RSS2.0 extension elements I was already generating, including OpenSearch. I don't know if any feed consumers actually support it in atom of course... I did noticed just now that OpenSearch 1.1 proposes an OpenSearch autodiscovery mechanism (amongst other things). Regards, Peter [1] http://www.ticketswitch.com/cgi-bin/atom_feed.exe -- Peter Robinson http://www.ticketswitch.com/
Re: round 2: Proposed Changes for format-11
Robert Sayre [EMAIL PROTECTED] wrote: The diffs linked below should reflect comments on the first round. A few more minor nits I'm afraid. (I don't think I've seen these discussed before.) http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt | Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also | an IRI, so a URI may be used wherever below an IRI is named. s/ below// You've replaced 'is needed.' with 'is named.' in the last clause. I'm not sure that's an improvement, or what was wrong with 'is needed.' in the first place. But if you don't like that, what about 'is required.' or 'is called for.'? You've also replaced 'a URI can' with 'a URI may'. Do you mean 'a URI MAY'? I suppose it depends on whether you see that sentence as a statement of fact or as part of the spec. Regards, Peter
Re: Atom Index Extension Proposal
James M Snell [EMAIL PROTECTED] wrote: FYI: http://www.snellspace.com/wp/?p=193 Abstract: Proposes two new elements that allow entries to be ordered within a feed. [xml condensed:] feed xmlns=http://www.w3.org/2005/Atom; xmlns:o=http://www.snellspace.com/atom/extensions/proposed; ... o:indexed / entry ... o:index1/o:index/entry entry ... o:index2/o:index/entry entry ... o:index3/o:index/entry /feed Certainly a very interesting idea. Having implemented openSearch [1] in my product feeds [2], I'd probably implement this, because it makes sense and would be very easy to do. My feeds are actually ordered (and paged) already, either by onsale date or by top seller, even though there's no way to indicate this in the XML. [Actually, it *should* already be in openSearch since that implicitly expects the feed entries to be ordered corresponding to the feed-level openSearch:totalResults and openSearch:startIndex elements.] Just my 2c. Regards, Peter [1] http://opensearch.a9.com/spec/opensearchrss/1.0/ [2] http://www.ticketswitch.com/cgi-bin/atom_feed.exe?page_no=2 (or http://www.ticketswitch.com/cgi-bin/rss_feed.exe?page_no=2)
Re: The Atomic age
Tim Bray [EMAIL PROTECTED] wrote: Paul assures me that the remaining IETF process steps will not introduce material technical changes, and so format-10 is appropriate as a basis for implementors to go to work. Excellent! So, implementors... to work. Just to show willing: http://www.ticketswitch.com/cgi-bin/atom_feed.exe Peter
