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

John Panzer jpanzer at aol.net
Tue Mar 21 10:58:08 PST 2006


Couple of minor notes below...

David Janes -- BlogMatrix wrote:

> 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.

Note: The Atom spec provides the atom:source element to handle this.  If 
an extension to hAtom is needed, that's probably the place to look.

>
>>
>> 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.

Actually, Atom doesn't require entry content, just advises that one of 
summary or content should be present:

> Experience teaches that feeds that contain textual content are in 
> general more useful than those that do not. Some applications (one 
> example is full-text indexers) require a minimum amount of text or 
> (X)HTML to function reliably and predictably. Feed producers should be 
> aware of these issues. It is advisable that each atom:entry 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry> 
> element contain a non-empty atom:title 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.title> 
> element, a non-empty atom:content 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content> 
> element when that element is present, and a non-empty atom:summary 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary> 
> element when the entry contains no atom:content 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content> 
> element. However, the absence of atom:summary 
> <http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary> 
> is not an error, and Atom Processors MUST NOT fail to function 
> correctly as a consequence of such an absence.

-John



More information about the microformats-discuss mailing list