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 _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
