[uf-new] hAtom is not a silver bullet

[Manu Sporny]

The argument has been put forth several times during the audio-info
exploratory process that hAtom should be used, directly, for publishing
information related to audio. Let us first understand what hAtom is:

"hAtom is a microformat for content that can be syndicated, primarily
but not exclusively weblog postings. hAtom is based on a subset of the
Atom (http://www.atomenabled.org/) syndication format." [1]

"hAtom is a microformat for identifying semantic information in weblog
posts and practically any other place Atom (http://www.atomenabled.org/)
may be used, such as news articles. hAtom content is easily added to
most blogs by simple modifications to the blog's template definitions." [2]

While hAtom /could/ be used for this purpose, I hope to outline several
reasons on why this is a bad idea. The main points that will be
addressed are:

1. The concepts identified for hAtom are not the same concepts that were
   identified for hAudio. The problem space is different.
2. hAtom has a very strong "syndication" background and is not fit for
   describing audio recordings. They are different solutions.
3. Extending hAtom to fit hAudio is a bad design approach, we must not
   allow unnecessary feature creep.

Confusing hAtom and hAudio Concepts
-----------------------------------

There have been several proposed mappings (both on the list and off of
the list) from hAtom to hAudio. One of them is used for example, but can
be extended to every hAtom-hAudio mapping proposal:

> work-title -> hatom entry-title

hAudio isn't specifying an entry in a blog or syndication. We are
talking about the title of a creative work. This is an important
distinction. The hAtom documentation states this for entry-title:

"an Entry Title element represents the concept of an Atom entry title" [3]

That concept is defined as the following:

"The 'atom:title' element is a Text construct that conveys a
human-readable title for an entry or feed." [4]

And further research shows that and entry is defined thusly:

"The 'atom:entry' element represents an individual entry, acting as a
container for metadata and data associated with the entry. This element
can appear as a child of the atom:feed element, or it can appear as the
document (i.e., top-level) element of a stand-alone Atom Entry
Document." [5]

Feed is also defined thusly:

"The 'atom:feed' element is the document (i.e., top-level) element of an
Atom Feed Document, acting as a container for metadata and data
associated with the feed. Its element children consist of metadata
elements followed by zero or more atom:entry child elements." [6]

'entry-title' is specifically meant for titles in entries, which the
language of hAtom and the Atom specification associate very directly
with syndication of content.

We should be making the argument that hAtom should be kept simple and
not extended. We should be saying that hAtom can encapsulate other
Microformats such as audio, video and image metadata.

hAtom is Strongly Related to Syndication
----------------------------------------

There is no denying the very strong link that hAtom has with
syndication. It is a fantastic Microformat for that purpose, it borrows
almost every one of its concepts from the Atom Syndication format:

"The Atom Syndication Format provides the conceptual basis for this
microformat, with the following caveats:

    * Atom provides a lot more functionality than we need for a 'blog
post' microformat, so we've taken the minimal number of elements needed.
    * the 'logical' model of hAtom is that of Atom. If there is a
conflict, Atom should be taken as correct.
    * the 'physical' model of hAtom -- the actual writing of elements --
is a lot more varied than Atom provides for, due to the variety of ways
weblogs are actually produced in the wild. The hAtom microformat
provides a number of rules for 'bridging the gap'" [7]

Even the Atom Syndication Format is very specific about what the format
is intended for:

"The primary use case that Atom addresses is the syndication of Web
content such as weblogs and news headlines to Web sites as well as
directly to user agents." [8]

Extending hAtom to Fit hAudio is a Bad Design Approach
------------------------------------------------------

"Atom is an XML-based document format that describes lists of related
information known as "feeds". Feeds are composed of a number of items,
known as "entries", each with an extensible set of attached metadata.
For example, each entry has a title." [8]

Pay particular attention to the phrase "with an extensible set of
attached metadata". This is what we mean when we say that hAtom should
encapsulate other Microformats, not be extended because "all we need is
two more elements to make this fix the Microformat problem of the day!"

We must fight feature creep into these formats, especially the
established ones, every step of the way.

-- manu

[1] http://microformats.org/wiki/hatom
[2] http://microformats.org/wiki/hatom#Introduction
[3] http://microformats.org/wiki/hatom#Entry
[4]
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14
[5]
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry
[6]
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.feed
[7] http://microformats.org/wiki/hatom#In_General
[8]
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.1