For better or worse, HTML is The Format. So why not use HTML as your underlying data format, producing other formats from it as needed? I’m convinced that this is how we should be thinking about webarch long-term. Other formats come and go, while HTML remains an unbroken line.
Ironically, my blog software uses Atom for its backing store.
With Microformats, of course, this is already being done. Authors link to services like H2VX to provide people with downloadable, subscribe-able vCard and iCalendar feeds. You can use hAtom2Atom to generate an Atom feed from your blog. Software like Falcon use HTML+hAtom for backend storage.
contains several new semantic elements, derived in part from Web
authors who have used
class="" to add additional
semantics to their markup.
pubdate> provide, in native HTML,
similar functionality to what the hAtom microformat
provides in HTML 4. (When
HTML5’s new elements are more widely
implemented, you can expect hAtom to be updated to encourage the
use of these new elements where possible.)
Hixie’s not the sort of
guy to leave things underspecified, so HTML5
defines (in excruciating detail) how
to convert an HTML document to Atom, even when
the HTML document in question is, shall we say,
less than ideal. Because documents can vary wildly in quality,
it is not always possible to extract an appropriate
<atom:id> for the articles present. We prefer to
errors, so in such cases the algorithm allows the
HTML→Atom software to make one up. Because
different software may make different IDs up, or even the same
software invoked in different circumstances, this doesn’t
quite live up to the
requirements of the Atom spec. This is unfortunate, but is
basically unavoidable in any such algorithm (hAtom, for
instance, punts on this issue entirely—it only defines the
conversion for valid input).