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. 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 metadata attached". 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 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. 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 <[EMAIL PROTECTED]> [1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
