Re: State of unique IDs on newsfeed items?

["Bill Kearney" <wkearney99@hotmail.com>]

> So it looks like it would be useful to have a unique ID on item as a
> hint to Readers. But how should the situation be handled where an 
Item
> is modified? Should this generate a new Unique ID or re-use the old 
one?
> If it re-uses the old one, then in practice, the Reader may miss the
> update as it is old in terms of the stream of items.

Yes, this is an interesting situation.  With e-mail and NNTP the ID 
on a message is generated when it's delivered.  The act of delivering 
generally makes the message become a read-only entity at that point.  
There are no (or very few) situations where the message gets edited 
as the original.

> Do we even need this?
> Well the vast majority of feeds have a globally unique value in 
<link>
> which is the URL of the html representation of the <item> (not some 
link
> in the item). Since all aggregators (?) already use this (if it's
> available) to check for uniqueness, nothing in the spec needs to 
change.
> So it looks like the only problem is the feeds that do something 
else
> with <link>, like leave it out altogether. 

I might not have made it clear.  I'm interested in a browseable link 
back to the item AND an XML structure.  One point being to allow 
people with browsers to go read the stuff from the site.  The other 
point being to allow someone with something smarter than a browser to 
ask the site what the SITE thinks is important about the item.  As 
in, when an item is interesting, there be a way to get MORE meta-data 
about the item directly from it's source instead of stuffing it all 
into a feed.

My example is routing an item.  Let's say you come across an item and 
want to redistribute the item.  If you just cut and paste you only 
pickup the visible info.  You can't easily or intelligently grab all 
the relevant info for the item.  Usually because it's be reformatted 
to 'look good' on the site.  This means the folks downstream from the 
repost aren't going to get anything other than what's been manually 
cut and pasted.  This generally makes the structure of the data even 
more obscure.  

So how about if an item has a link back to it's genuine 
representation in XML from it's source?  This way you could tap into 
the rich meta-data found on the source to make your repost more 
informative.  Like being able to grab the correct author e-mail 
address, the site's categorization of the item or more.  Stuff that's 
really valuable in a drill-down situation instead of a cursory 
headline review.

> So it seems to me that a new element is *not * needed. We just need 
to
> persuade the existing feeds to use <link> and make sure it is 
globally
> unique. Since only a small proportion of them fail to do this 
already,
> this ought to be an easier task than persuading the larger 
proportion to
> add a new element.  

Yes, if all you want is a link back to the HTML viewable item on it's 
website.  But if you want something more you're SOL with using that 
tag.

In handling edited materials, I don't know what to say.  On one hand 
it would be good to consider an item being put into a feed as read-
only.  But I can see several folks having a problem with this idea.  
On the other hand, things like blogs and such are in a constant state 
of flux and don't work in this fashion.  Considering most feeds are 
grabbed as snapshots at a given time, edited items resurface in 
future snapshots as new postings.  This means (at some point) they've 
got some kind of timestamp associated with them.  Perhaps that's 
something for the local client (or aggregator) to consider when 
encountering an existing ID in a new snapshot.  

This is where versioning starts becoming useful.  I see versioning 
being even more difficult for existing systems to handle and possibly 
of very little value.

I don't want the discussion of 'more intelligent' link tags to become 
mired in a debate about edited feeds.  So can we fork it here?

-Bill Kearney