I haven't done much deep thinking about this proposal yet, but the one thing that concerns me are the non-atom resources that go along with the entries. When I export from a blog, I want to be able to export everything in a single operation. I've been stewing lately over the possibility of doing something similar to this but wrapping the atom documents and associated resources into a zip. A single master atom feed would provide an index of the archive, with individual entries either contained in that index feed or as separate entry documents (modeled loosely after the distinction app makes between the collection feed and individual editable entries.
- James Bill de hOra wrote: > > Alastair Rankine wrote: >> >> Hello Atom folks, >> >> Here is a proposal for an Atom-derived format for exporting of content. >> >> The problem I'm trying to solve is that of migration from one >> authoring system (eg blogging engine) to another. Atom is highly >> suited to this task. >> >> The full problem statement, and the reasons for basing the solution on >> Atom, are all described in the proposal published here: >> >> http://girtby.net/offerings/atomexport >> >> There is no implementation yet. >> >> I look forward to your comments on this document. > > > Very quickly (I'm overloaded atm) - this is excellent. > > I've been looking at using Atom Entries for roundtripping/backup and > interchange, especially in CMSes, for some time. The ultimate dump > format in terms of expressiveness is RDF/XML, but it can be complicated. > Atom offers a lot of value with comparative simplicity largely because > atom:id can survive across systems*, but also because the flat format of > entries maps well onto relational data (it's particularly good for > dumping metadata). One hard problem is in usefully storing and indexing > received foreign markup. > > cheers > Bill > > * that said, for "consumer" data, the APP leans towards, or least > allows, rewriting of atom:ids due to trust issues. > >
