I think the navigation elements of draft-nottingham-atompub-feed-history-04.txt overlap with Atom protocol navigation and deployed APP beta implementations. In fact, I pointed this out way back in April 2005. I don't think anything has changed.
In <http://www.mnot.net/blog/2005/04/12/feed_state> Mark Nottingham wrote: > Way back when I put the first Atom drafts together, I included a placeholder > for > a section that I hoped would allow reconstruction of feed state. Presently, > this often > isn't necessary, because you have to be away for a seriously long time > (e.g, on vacation) before you actually miss anything. ... > In other words, if you happen to look away for too long you miss information, > essentially making the channel leaky. To that end, I put together a proposal > and a > demonstration feed (in fact this very blog's feed, dear reader), in the hopes > of > convincing people that this is a real issue. Silence ensued, and the > ATOMPUB WG declined my proposal. to which Robert Sayre replied: > Hmm. Your proposal concerned a couple link relations, right? Those would be > easy to add to the format at anytime, and... Blogger and 6A have both asked > for > similar functionality on the protocol side. Seems like more of a server > layout > and protocol problem, anyway. to which Mark Nottingham replied: > Robert — > The only problem I have with that is that AFAIK so far, I don't need to know > about the > protocol document to consume an Atom document; it's only when you want to > manipulate a feed that you have to work on that side of the house. > > That said, it's good to hear that others want this too. to which Robert Sayre replied: > Well, wouldn't it be nice if you didn't need to know about the protocol > document to > perform any of the protocol's read operations? That's my thinking. > View-source on a > couple of link relations should be enough to pick it up. Robert Sayre
