On 03/10/2006, at 12:21 AM, Elliotte Harold wrote:

XOP, if I understand it correctly, could in fact be packaged in a zip file, though no such packaging is described in the spec. If you went with a non-XOP zip as opposed to XOP, I suspect you'd probably end up reinventing a lot of XOP along the way. If you could get away with 20% of XOP, then it might be worthwhile to do something custom. Otherwise, I'd just go with XOP.

Just to kill my own suggestion... Now that I have read the spec and thought about about it there is a good reason for *not* using XOP for the purpose of exporting content: it's simply that the resources that accompany an Atom feed -- such as images referenced within the XHTML, enclosures, etc -- do not form part of a larger XML infoset. If the resource were part of the XML of the Atom feed, you could use XOP as an alternative to base64-encoding it. But because the referenced binary objects are separate entites (in the generic non-XML sense of the word), I don't think XOP is applicable here.

Another possibility: OpenOffice does something very much like this (zipped XML + media). Does anyone know if that format is sufficiently generic to handle this use case?

After a quick scan (http://hacks.oreilly.com/pub/h/2097) I'd say almost certainly, but it adds a lot of other stuff which may or may not be useful for Atom export.

Instead, how about this: a zipfile with a single "index.xml" file containing the Atom export document (as currently proposed), with all other resources added to the zipfile according to their relative URLs from the site being exported.

Say we had a blog at http://example.com which in turn referenced images at http://example.com/images/* and enclosures at http://example.com/enclosures/*, the resulting zipfile would contain:

index.xml
images/1.jpg
images/2.jpg
...
enclosures/1.mp3
enclosures/2.mp3
...


Seems simple enough, but there's almost certainly some complexity that I'm overlooking.

Reply via email to