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