[uf-discuss] hAtom draft - utility of feeds
benjamincarlyle at optusnet.com.au
Sun Dec 25 22:05:04 PST 2005
On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> Have at it:
I have been thinking a little about what feeds are and what they will be
used for. Currently my own mostly-hAtom-formatted blog has no feed
element. Essentially, the page is the feed. Are feed elements useful?
Are they required? I have been having the following arguments with
Argument 1: They exist in atom, so should exist in hAtom
<feed> is the top-level element in atom, amounting to <html>. Only one
is ever permitted in a single document. Contrast this to the current
proposal to allow multiple class=feed elements within a hAtom document.
I think this argument is invalid.
Argument 2: They exist in the wild, so should exist in hAtom
My blog does not currently have a div around its class=entry elements,
so this is not univeral. I suspect my blog is in a minority, but I think
this argument is still invalid.
Argument 3: Web pages with multiple feeds on them exist in the wild, so
hAtom should support multiple feeds in a page
This is probably the central argument at present, but it is perhaps
useful to consider how hAtom might be used in the future. Let's first
look at the examples:
Google News <http://news.google.ca/nwshp?hl=en&tab=wn&q=> lists entries
grouped by category. It provides a single atom feed for this page at
<http://news.google.ca/nwshp?hl=en&tab=wn&q=&output=atom> which combines
entries into a single page-ordered feed.
The Truth Laid Bear <http://www.truthlaidbear.com/topics.php>. This page
does not provide an atom alternative but follows the basic "by-category"
ordering used by google.
Are these separate feeds, or is it a single feed ordered by category?
Personally I would lean towards the latter interpretation. "The Truth
Laid Bear" also includes a miniblog which contains advertising. I would
guess that if they did provide an atom feed they would prefer to see
these entries included within than left out, or in a separate feed.
In short, I am not sure I have seen a case yet where multiple feeds
exist on the one page. Order of blog entries can be defined by the
publisher as either by-date or by-category, but these may still be
placed in a single feed structure.
I kind of feel that hAtom may be better off without a feed element, not
only because of the reasons above but because it might improve hAtom's
applicability. I think it would be a simpler standard if it didn't
define a feed level (and it subsequent interacton with the entry level).
If it specalised to do entries really well then I imagine that non-blog
uses might appear also to take advantage of the entry concept. Entry now
becomes something like "a piece of content with author and publication
This also brings to light the question of what a parser should do with a
page that contains multiple feeds. A valid Atom document can't be
produced. Multiple documents would be required. In fact, I think the
absence of explicit feed elements might make more sense. A client could
point at http://example.com/blog/ in order to get an atom feed of
everything on the page, or at http://example.com/blog/#Iraq to locate
the element with id=Iraq and any elements contained within it. In
essence this approach would allow a hierarchical but otherwise freeform
feed construction on a hAtom page that contains particular subsets of
I just want to also question the utility of marking up single-entry
feeds such as
Atom is primarily used to monitor web pages for changes, and I would see
that as the primary market for hAtom for the near future. A single entry
feed is (by definition?) one that won't change, thus subscribing to it
or syndicating it doesn't necessarily make sense to me. I can possibly
see how entries such as these could help search engines, but I don't
have a specific use case in mind at all. I guess the question is "How
does a single-entry hAtom feed differ from the web page that would
otherwise be there"? Thoughts?
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
More information about the microformats-discuss