[uf-new] Comments proposals

[David Janes]

Response #2

On Sun, Nov 16, 2008 at 5:56 PM, Sarven Capadisli <csarven at gmail.com> wrote:

> Martin brought up a while back whether if anyElement in atom:content
> includes atom:feed. I couldn't get to the bottom of this either so
> I've tested this [2] and it does seem to be valid according to the
> Atom validator (if I didn't make a mistake) [3] and if the validator
> is accurate. However, the nested feed (type=application/atom+xml)
> appears to be lost when I gave it a go in Firefox, Opera, IE7, and
> Google Reader. If anyone could elaborate on their findings or
> interpretations, that would be great. Toby did mention that it is not
> allowed (even though possible to parse but doesn't hang on to the
> nested relationship currently) [4] and multiple hfeeds is a no go as
> far as the current definition goes in the Wiki [5] Doesn't this mean
> that we can't nest an hentry inside of another hentry? If we go this
> route we may need to change the hfeed property slightly. Am I missing
> something here? Where do we stand on this?

*We* decide how HTML marked up with hAtom maps into Atom. The fact
that we can nest an Entry Feed in an Entry _does not_ imply that such
a structure has some sort of direct meaning in Atom: it is simply
something that's happening in HTML world.

Note that this is an inherently good point, passim discussions when we
created hAtom that we'd not disallow nesting of Entry Feed; but we
decided at the time not to give it "meaning"

Note that your link "[5]" points to the the cheatsheet, not the hAtom
spec: hAtom does not preclude nesting of Entry Feed [1].

Regards, etc...

[1] http://microformats.org/wiki/hatom#Feed
"[5]" http://microformats.org/wiki/hatom-cheatsheet

-- 
David Janes
Mercenary Programmer
http://code.davidjanes.com