Subject: Reviving Atom Export

From: Alastair Rankine <[email-masked]>
Date: Mon, 11 Dec 2006 20:29:38 +1100

So I got a bit distracted for a bit. Here's what we were talking about.

### What is it?

Atom Export is a proposal for a standard/convention/something for the  
export of content from a CMS (think blogging engine) in a format that  
is similar to other Atom standards. The assumption here is that the  
content being exported is a good fit for Atom. I believe this to be  
the case (hence discussing it on this list) but it is not established  
yet.

More rationale, and initial attempt, here: http://girtby.net/articles/ 
2006/08/14/towards-a-common-blog-export-format

### Where did we get up to?

We have a list of requirements for the export format, specifically  
the data from a typical blogging engine that should be included in  
the export. We also had identified some preliminary issues with  
representing the content in an Atom-based document format. Lastly we  
had clarified some scope, namely that the primary use case should be  
for migrating from one content engine to another, and not necessarily  
for backup purposes within a single application.

### What data is to be represented by this?

Here is a list of data to be included in the export. For convenience  
a blog engine is assumed, although other compatible CMSs may  
implement this as well:

    1. Complete list of authors defined. For each author:
          1. Name
          2. URI
          3. email
    2. Complete list of categories defined:
          1. Name
          2. URI
    3. All articles. For each article:
          1. Source text
          2. All the relevant metadata from the Atom spec, namely:  
author, ID, published, rights, title, updated, summary, categories
          3. Some other metadata: draft status, syntax of source
    4. All comments and trackbacks. For each comment or trackback:
          1. Source text
          2. Atom spec metadata: author, ID, title, published,  
summary, avatar?
          3. Additional metadata: pointer to parent article or  
comment (ie "in-reply-to")
    5. All "Owned" media. For each media object:
          1. URI
          2. MIME type
          3. Binary data

### What are the issues identified so far?

Briefly:

  * It was felt that the inclusion of binary media objects warrants  
the use of a binary archive format. The issue of how to organise the  
content within the archive file is unresolved.
  * There was some discussion about the inclusion of generated text,  
specifically HTML generated from the source text. It is redundant but  
may be useful.
### What now?
I think the best way to proceed is to propose a fresh mapping of the  
above data requirements to Atom-derived constructs. I already had a  
go at this previously, but I think it might be better to start  
afresh. This time I'd like to try an approach based around the  
concepts introduced in APP, particularly that of collections, which  
look like a good fit for items 3,4, and 5 above.