[uf-discuss] multiple hatom feeds in one document.. can it work?
Chris Casciano
chris at placenamehere.com
Mon Jun 12 17:04:27 PDT 2006
On Jun 12, 2006, at 7:08 PM, Scott Reynen wrote:
> On Jun 12, 2006, at 5:01 PM, Benjamin Carlyle wrote:
>
>> A user selects from the feeds
>> thusly:
>> http://example.com/feeds#techjobs
>> http://example.com/feeds#videos
>> A client's user interface can use descriptions of the feed (as
>> specifications emerge) to help the user choose something
>> human-friendly.
>
> I seems to me a little awkward to be using IDs intended for machine
> consumption as pseudo-titles for humans to distinguish between feeds.
> Doesn't the HTML already have H# tags acting as titles for the
> sections being used as feeds? Is there a reason those aren't being
> used as human-friendly feed titles?
>
> Peace,
> Scott
>
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]
* 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.
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 ]
More information about the microformats-discuss
mailing list