[uf-discuss] What to do when a microformat doesn't quite fit?
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  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
> element contain a non-empty atom:title
> element, a non-empty atom:content
> element when that element is present, and a non-empty atom:summary
> element when the entry contains no atom:content
> element. However, the absence of atom:summary
> is not an error, and Atom Processors MUST NOT fail to function
> correctly as a consequence of such an absence.
More information about the microformats-discuss