Using XOP is definitely an option, but it's one that is likely to be far less efficient and likely quite a bit more complicated than a zip. Using the zip gives you quite a few options for exporting multiple collections, with associated resources, templates, configuration settings, plugins, whatever. Exporting the media resources is, at the very least, a very important requirement for the types of cases we'd be looking at to use this.
- James Alastair Rankine wrote: > Thanks for the initial feedback. > > It is a common dilemma for spec writers to decide when to stop. In this > case: should the spec include non-atom resources or not? > > I initially thought not because it didn't seem to fit easily but perhaps > I was too hasty. There are some potential users of this whose important > content is almost exclusively in binary format, such as podcasters. On > reflection it seems an unwise exclusion. > > So I haven't thought about this much either, but a couple of options > present themselves. As you say below, zipfiles may be a good solution. > There is also the XOP format (http://www.w3.org/TR/xop10/) which looks > pretty suitable also. Of these two I lean towards zip, but I would have > to think about it some more. > > Any other suggestions or comments? > > > On 28/09/2006, at 6:38 AM, James M Snell wrote: > >> >> 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. >>> >>> >
