[uf-discuss] multiple hatom feeds in one document.. can it work?

[Chris Casciano]

On Jun 12, 2006, at 8:04 PM, Chris Casciano wrote:

>
> After some chatting on IRC a week or two ago I see two core issues 
> that need to be discussed and turned into either spec or guidelines:
>
> * What are the holes in the spec that create ambiguous cases? How can 
> they be eliminated gracefully. As written now, and acceptable for 
> single feed pages, both an id attribute and the hatom'd element are 
> optional. Requiring both if there are two feeds might be the most 
> direct option to fix it, but I'm still not sure I like the scenarios 
> it brings up[1]

Going to reply to my own post to point out a specific case from my 
examples that I found interesting:

this is clearly feed 2:
http://placenamehere.com/mf/hatom_tests/test_4a.html#otherposts

Is this specific enough for feed 1?
http://placenamehere.com/mf/hatom_tests/test_4a.html#rootbody

Is this still feed 1?
http://placenamehere.com/mf/hatom_tests/test_4a.html



(btw, as i was looking this up I saw a minor bug with a repeated ID on 
the entries.. didn't impact the feed discussions, but its fixed now)

>
> * If we have a spec that guards against ambiguous cases do we need any 
> rules or guidelines for consuming apps? I'm concerned with (A) initial 
> selection of a specific feed, or not (tantek brought up the potential 
> of using hatom source) (B) Consumption of a specific feed (this 
> shouldn't be an issue) (C) How to deal with changes to the HTML 
> document that might impact a subscription.
>

And just to provide an example of (C)  look at the tests a different 
way and not as isolated cases, but as changes to a document over time. 
Perhaps you have a page, and are subscribed to a feed at following 
address:

http://placenamehere.com/mf/hatom_tests/test_1a.html

- one day a redesign comes along and makes it look like this:

http://placenamehere.com/mf/hatom_tests/test_2a.html

What does the consuming application do?? Is that considered a different 
feed?

- or maybe the redesign adds a link feed and results in something like 
the following:

http://placenamehere.com/mf/hatom_tests/test_4a.html

- or instead of a redesign, some content comes into a post that makes 
the page look like this:

http://placenamehere.com/mf/hatom_tests/test_6a.html



I'm not saying that the spec needs to deal with these scenarios and 
make them all legal (or illegal), but I do think these cases need to be 
considered in some fashion and some guidance provided to both authors 
as well as developers of consuming apps about what constitutes a 
specific "feed" and how changes to documents may result in offering 
"different" feeds.

> I haven't had time (a few site launches I'm in the middle of.. not 
> much MF related there however) to write all this down in the 
> hatom-issues page yet but I did build a set of examples[2] of 
> different currently legal cases of multiple feeds in a document so you 
> can see for yourself where some things are ambiguous now, and some 
> things are just another case to deal with. Short of a real site[3] 
> that has more then one feed on it I thought this made the best example 
> for discussion. Please poke at them and provide feedback
>
>
> [1] blog index is marked up as an hatom feed leaving the root element 
> out never intending another feed.. then one day a post happens to 
> contain a feed of its own... you're "invalid" now on index pages with 
> that post.. yeah.. i know.. edge case but.. it makes me weary
>
> [2] http://placenamehere.com/mf/hatom_tests/
>
> [3] http://placenamehere.com/mf/netnewswire/ :: One of the potential 
> cases of this is on my NNW plugin page.. .where I currently have a 
> short feed with version information.. .were I to have time to redesign 
> PNH I'd wrap a larger portion of the page in something one could 
> subscribe to, but at that point I'd either have to pull the small feed 
> or hope someone subsribing to it doesn't choke on the updated page
>
> -- 
> [ Chris Casciano ]
> [ chris at placenamehere.com ] [ http://placenamehere.com ]
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
-- 
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]