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 ]
[ [EMAIL PROTECTED] ] [ http://placenamehere.com ]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
--
[ Chris Casciano ]
[ [EMAIL PROTECTED] ] [ http://placenamehere.com ]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
