[uf-discuss] What to do when a microformat doesn't quite fit?

David Janes -- BlogMatrix davidjanes at blogmatrix.com
Tue Mar 21 10:34:48 PST 2006


Angus McIntyre wrote:
> These lists of articles - which are essentially 'feeds' - seem like an 
> obvious match for hAtom, so I've tried to make the library produce 
> hAtom. However, there are some problems.
> 
> First, hAtom demands an author - either at the entry level, or at the 
> feed level - and in these two use cases, there's no obvious author. In 
> the case of the Inca Trail collection, the articles linked to sometimes 
> have authors and sometimes don't. I could put myself as the 'author' of 
> the collection as a whole, but I'm not sure that makes strict sense.

I would suggest going with your latter option, even though it's a little 
ugly. At that point, we're really constrained by the Atom spec and in 
some technical sense you (or some contact at your organization) is the 
author of the "feed" even though you're not the person creating the 
content of the individual entries.

> 
> Second, hAtom demands 'entry-content' and makes 'entry-summary' 
> optional. In the first example, there's neither content nor summary 
> (because that's how the client wants it). In the second, the text is 
> really more in the nature of a summary than content, but content is the 
> required item.

Atom demands entry:content, hAtom assumes it's the empty string [1] if 
you don't add it.

> Finally, the articles all have a 'source' (i.e. the publication where 
> they appeared), but I'm unclear on how to represent that in hAtom.

It's always OK to add new things semantic elements, though obviously 
others won't know what they are -- until they're added to the hAtom spec:

- looking through the Atom spec (especially here [2]) for something you 
can use ("via"?) and bring it back to the group for discussion
- raise an issue in hatom-issues [3] for what's missing and what you

[update] I've just looked at what you've done. It's OK as-is [4,5].

> What's the best course of action in cases like these? My use-case 
> doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' 
> and 'content' requirements. But at the same time, it looks as if hAtom 
> fits better than anything else. Should I
> 
>   a. Force my listings into the hAtom mold, by calling the summaries
>      'content' (and putting in an empty content block in the first case),
>      and adding an author somehow, or
>   b. Avoid using hAtom at all, on the grounds that if I can't meet the
>      requirements, I shouldn't deceive innocent robots by promising them
>      hAtom and not delivering?

a. is not an issue -- call your summaries "entry-summary" and 
"entry-content" will default to the empty string

Beyond that, I think you're OK except for the author ugliness. I just 
ran it through the AUMFP and it looks like it's going in the right 
direction.

Regards, etc...
David

[1] http://microformats.org/wiki/hatom#Entry_Content
[2] 
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rel_attribute
[3] http://microformats.org/wiki/hatom-issues#hAtom_0.2
[4] 
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7
[5] http://microformats.org/wiki/hatom#Entry_Permalink



More information about the microformats-discuss mailing list