[uf-discuss] hAtom draft

Benjamin Carlyle benjamincarlyle at optusnet.com.au
Tue Dec 20 20:57:58 PST 2005


On Tue, 2005-12-20 at 12:05 -0800, Ryan King wrote:
> On Dec 20, 2005, at 7:44 AM, Benjamin Carlyle wrote:
> > Reading the information from
> > that atomenabled.org I'm inclined to write the parser as only placing
> > author and contributor elements in an entry when they appear in the
> > hAtom html within an entry. If author and contributor fields were only
> > to be found at the feed level I would only repeat them there in the  
> > atom
> > output. Is my inclination reasonable? That would make any atom feed
> > reader responsible for making the association between a feed with a
> > particular author an each entry having a particular author rather than
> > the transform...
> I'm not sure I follow what you're saying here.
> Are you saying that when you transform to Atom, you're inclined to  
> replicate the author information on every entry?

My current implementation looks within a class=entry for author and
contributor details. If it finds none it searches the feed (or
approximately so, the implementation is currently a little hacky) for an
author and places it within the <atom:entry> on output. If the feed has
an author it will be duplicated within each entry.

My inclination is to drop this processing, and only place atom:author
and atom:contributor where they appear in the source document. If they
appear at the feed level they are placed there. If they appear at the
entry level they are placed there. If they occur in both they are placed
in both. If they occur in neither they are placed in neither.

On Tue, 2005-12-20 at 15:29 -0500, David Janes wrote:
> The Atom spec layers further requirements in the text, specifically
from the 
> Recommended Elements [4]
> "Names one author of the entry. An entry may have multiple authors. An entry 
> must contain at least one author element unless there is an author element 
> in the enclosing feed, or there is an author element in the enclosed source 
> element."

Ok, I took this on my reading as indicating that an author or
contributor at the atom:feed level would negate the need to provide
these fields on each atom:entry. But this:
> Right now, the 
> hAtom spec does not define author (or contributor) at the feed level
is certainly pause for thought. If it isn't legal to put them at
the atom:feed level or the meaning of the elements at the atom:feed
level is unclear copying the information into atom:entry nodes on
transform to atom would seem reasonable.

> - have you seen a blog where the Author is specified outside the
> (and not in the entries)? I.e. are we inventing edge cases that don't really 
> exist?

I think this is fairly typical. My blog is a case in point.
Individual entries may be tagged with minimal author information
(I sign off with "Benjamin"), but information such as email address
and the like tend to be situated only once on the page. This detail
would seem the more useful set to include.

Here is a quick survey of some current members of my blogroll
(a quick subset only). I have only selected personal blogs
which will typically have only one author. vcard means either
an actual hcard or information that could be reformatted as a hcard.

No vcard data (3):

Feed vcard only, no entry vcard (2):
	- Name and uri, etc at top of page. No individual entry signoff.
	- Email addres, job description, etc. No entry signoff.

Entry vcard only, no feed vcard (4):
	- Posted by, with hyperlink for uri.
	Also, "about" link... but not really vcard-compatible.
	- "man-di" in post header?
	- "posted by" signoff
	- "posted by" in post header

Feed vcard + Entry vcard,
but with additional detail in the "feed" vcard (2):
	- About Me section + "posted by"
	- Tales from the homeworld poput + "Benjamin" sign-off

I would not indicate vcards for the signoff in the last
section, only marking author and contributor at the feed
level where more data is available. This would effectively
put them back into the "feed vard only" set, bumping its
count up to 4. Also, the feeds that do provide entry-level
vard information tend to keep it to just a name or name+url.

I don't know whether these figures are at all representative
of the general blog population. I started at the bottom of
my list of feeds in order to pick up some non-technical blogs.
I'm hoping this makes the figures remotely valid.

Benjamin Carlyle <benjamincarlyle at optusnet.com.au>

More information about the microformats-discuss mailing list