Subject: Feed History -04

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Sep 2005 16:18:29 -0700

Feed History -04 is out, at:
   http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt

Changes:
   - fh:stateful -> fh:incremental, with appropriate changes in text
   - more explicit cardinality information
   - implications of fh:prev being an Absolute URI spelled out
   - more explicit white space handling
   - Acknowledgements section

More information, including implementation details, at:
   http://www.mnot.net/blog/2005/09/05/feed_history

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Sat, 10 Sep 2005 12:31:12 -0700

Mark, this is looking very good.  One point, however.

For non-incremental feeds, it would be helpful to have the option of 
being able to reference archived version of the feed (e.g. prior 
top-ten-lists).  This could be accomplished by allowing fh:prev elements 
in a feed with fh:incremental set to false.

<feed>
  ...
  <fh:incremental>false</fh:incremental>
  <fh:prev>http://www.example.com/oldfeed</fh:prev>
</feed>

means that http://www.example.com/oldfeed is the previous (I hate to use 
the word) "version" of the feed.

thoughts?

- James

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Sep 2005 17:45:26 -0700

Hi James,

That was discussed before in the thread whose Subject was "Feed  
History -02", starting in mid-July.

My position is that the semantics of fh:prev and those of a "get me a  
non-current view of this feed document' are potentially -- and even  
often -- orthoganal. fh:prev is a link that allows you to reconstruct  
a feed whose entries are *all* current. Because of this, it isn't  
good to re-purpose the element for what you want; something separate  
would be better.

Also, Henry Story had some interesting thoughts about how to best  
model "top 20" lists, which had some impact on the issue you raise.

Cheers,

On 10/09/2005, at 12:31 PM, James M Snell wrote:

> For non-incremental feeds, it would be helpful to have the option  
> of being able to reference archived version of the feed (e.g. prior  
> top-ten-lists).  This could be accomplished by allowing fh:prev  
> elements in a feed with fh:incremental set to false.
>
> <feed>
>  ...
> means that http://www.example.com/oldfeed is the previous (I hate  
> to use the word) "version" of the feed.
>
> thoughts?
>
> - James
>
> Mark Nottingham wrote:
>
>
>>
>>   http://www.ietf.org/internet-drafts/draft-nottingham-atompub- 
>> feed- history-04.txt
>>
>> Changes:

---

From: James M Snell <[email-masked]>
Date: Sat, 10 Sep 2005 19:11:58 -0700

Ok, I guess I missed that prior discussion (or just completely forgot 
about it).  I'll go back and review that conversation and Henry's 
suggestions.  Thanks!

Mark Nottingham wrote:

>> means that http://www.example.com/oldfeed is the previous (I hate  to 
>> use the word) "version" of the feed.
>>
>> thoughts?
>>
>> - James
>>
>> Mark Nottingham wrote:
>>
>>
>>>

---

From: "James Holderness" <[email-masked]>
Date: Mon, 12 Sep 2005 01:39:34 +0100

I also have a question regarding the fh:incremental element. While the spec 
says it SHOULD occur, and it MAY be assumed "true" if the document contains 
a fh:prev element, it doesn't say how to interpret a document which has 
neither fh:incremental nor fh:prev (which is exactly the status of most 
feeds in existence). The most obvious interpretation would be to assume an 
fh:incremental value of "true", but if that's the case why bring up the 
issue of whether the fh:prev element is present or not?

On an unrelated note, shouldn't the default namespace in the atom examples 
be "http://www.w3.org/2005/Atom"?

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 13 Sep 2005 13:53:38 +0200

> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 

Good! I think it is now easy to understand where the spec applies and  
how the different elements interact. I just wish I could think of some  
terms which better fit to each other.

Very, very minor:
Ch. 3 Make the 3rd paragraph the first. Explain what fh:incremental  
does before explaining why and where it might appear or not.

Cheers,  Stefan

---

From: Henry Story <[email-masked]>
Date: Thu, 29 Sep 2005 19:21:44 +0200

I think this is good, but I would prefer the atom:link to be used  
instead of
the fh:prev structure, as that would better fit the atom way of doing  
things.
I also think it may be very helpful if we could agree on an extension  
name space
that all accepted extensions would use, in order to reduce name space  
clutter.

Henry

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Sep 2005 10:38:39 -0700

Hi Henry,

Thanks for the feedback. As I've explained before, I have a pretty  
strong preference for the current design, to make it usable in other  
formats; i.e., the scope of this is not just Atom (which is why I'm  
probably going to do it as an Individual submission).

One path forward would be to have a special case of fh:prev, just for  
Atom, where it was spelled atom:link. I'm not crazy about this, as  
exceptions are generally bad, and because it would require  
implementors to special-case their code; i.e., they'd have to look  
for one element if it's an RSS feed, and a different element if it's  
an Atom feed. I know this is already done widely, but I see no reason  
to artificially require the practice here. However, if a number of  
implementors stand up and say that they wouldn't mind such a special  
case, and no one is against it, I'd make the change.

WRT namespaces, I agree that namespace clutter isn't great, but it's  
hard to avoid while still getting the benefits of namespaces. Perhaps  
once there are a lot of extensions that are used in day-to-day  
practice, someone will package them up into a bigger, wrap-up  
namespace that contains everything.

Cheers,

On 29/09/2005, at 10:21 AM, Henry Story wrote:

> the fh:prev structure, as that would better fit the atom way of  
> doing things.
> I also think it may be very helpful if we could agree on an  
> extension name space
> that all accepted extensions would use, in order to reduce name  
> space clutter.
>
> Henry
>
>
>> feed-history-04.txt

---

From: "James Holderness" <[email-masked]>
Date: Sat, 1 Oct 2005 01:05:30 +0100

Mark Nottingham wrote:
> Thanks for the feedback. As I've explained before, I have a pretty  strong 
> preference for the current design, to make it usable in other  formats; 
> i.e., the scope of this is not just Atom (which is why I'm  probably going 
> to do it as an Individual submission).

At first I thought this was a good idea, but I'm starting to have second 
thoughts. The spec as it stands is fine for RSS 2, but I can see a lot of 
Atom people thinking that you should be using atom:link (as Henry suggested) 
and not wanting to "corrupt" their nice new format. No doubt the RSS 1 folks 
have their own preference for where this should be going and will probably 
be even more adamant that you do things the correct way (not sure what that 
might be - something using dc:relation maybe?) I would worry that if they 
don't like it, they won't use it.

> implementors to special-case their code; i.e., they'd have to look  for 
> one element if it's an RSS feed, and a different element if it's  an Atom 
> feed. I know this is already done widely, but I see no reason  to 
> artificially require the practice here. However, if a number of 

I'm not exactly a high profile implementor, so my opinion may not matter 
much, but I personally wouldn't have a problem with it. I already keep the 
Atom code separate from RSS with the hope that one day the RSS can be thrown 
away, so this really wouldn't affect me at all.

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?

Regards
James