[uf-discuss] hAtom draft - utility of feeds

Benjamin Carlyle benjamincarlyle at optusnet.com.au
Tue Dec 27 06:21:40 PST 2005


Ryan,

Rather than trying to get into too detailed a discussion over email I'll
try to catch you in irc some time. Email isn't the best forum for the
resolution of technical questions :)

I'll just summarise my main feelings at this time:

* The hAtom specification does not define any child elements of a
class=feed element, except for class=entry elements. The specification
is at a tipping point where the additional feed-level elements could all
be defined or all be left out. I lean towards the latter, except for the
definitions of the required <atom:id> and <atom:updated> fields. These
are the only things missing from the current specification required to
translate hAtom to valid Atom.
* I think that the <atom:entry> concept is more important than the
<atom:feed> and is in a good state in the current hAtom. I think
defining the set of elements for <atom:feed> may be a case of
diminishing returns.

I will do some more thinking about how feeds would work in the examples
currently available. I am in two minds as to whether I feel they should
be available for use or not. It seems reasonable to be able to define
disjoint feeds on a single page, but these would have to be addressable
using id attributes for parsers to subscribe to them. Nested feeds would
not be supported, but categorisation within a single feed could affect
ordering and presentation in a client such as a feed reader.

On Mon, 2005-12-26 at 08:43 -0600, Ryan King wrote:
> On Dec 26, 2005, at 12:05 AM, Benjamin Carlyle wrote:
> > 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.
...

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>



More information about the microformats-discuss mailing list