[uf-discuss] hAtom draft - utility of feeds

Mon Dec 26 06:43:30 PST 2005

On Dec 26, 2005, at 12:05 AM, Benjamin Carlyle wrote:
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
>
> I have been thinking a little about what feeds are and what they  
> will be
> used for. Currently my own mostly-hAtom-formatted blog[1] 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
> myself.
>
> 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.

When creating microformats, we explicitly try to keep things  
compatible with existing formats, so that they can be transformed in  
a reasonably easy way. We've made compromises with hcard, hcalendar  
and hatom for precisely this purpose. I don't 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.

Once again, I think this argument is invalid- we're explicitly  
designing for the majority, even if it means the minority gets ignored.

> 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?

 From the perspective of someone working on the spec, it doesn't  
matter. Google can choose to do it either way.

> 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.

There are a number of blogs which syndicate other feeds into their  
blog. While this isn't the most interesting case for syndication, we  
should still be allowed to mark up those bits of content as feeds  
('cause that's what they are).

> 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
> metadata attached".

I don't think so. So far, all you need to have a feed is  
class="feed." I don't think this is much of a burden, and you can  
always apply it to the <body> tag, if you want your entire page to be  
the feed.

> 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.

I'd say just return the first one.

> 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
> class=entry elements.
>
> I just want to also question the utility of marking up single-entry
> feeds such as
> <http://www.microformats.org/blog/2005/09/30/web-essentials-audio/>.
> 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.

Blog posts can and *do* change. There's no argument here.

Plus, remember, hAtom, though its use case is syndication, is also  
useful in that it *applies semantics,* which can be parsed and  
understood by user agents. For example, the guys at Flock could use  
hAtom markup for doing proper citations when quoting blog posts. Mo'  
data, mo' betta.

> 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?

More explicit semantics. 'nuff said.

-rk

> -- 
> Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
> [1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

--
Ryan King
ryan at technorati.com