Subject: draft-sneddon-atom-export (Was: Exporting a blog using Atom)

From: Geoffrey Sneddon <[email-masked]>
Date: Wed, 25 Mar 2009 22:59:49 +0000

On 7 Oct 2008, at 04:15, Andrew da Silva wrote:

> While talking with Geoffrey Sneddon, he suggested using several Atom  
> documents, makes sense.

See also:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Atom Export Format
> 	Author(s)       : G. Sneddon
> 	Filename        : draft-sneddon-atom-export-00.txt
> 	Pages           : 7
> 	Date            : 2009-03-23
>
> This document specifies a method of using the Atom Syndication Format
> as an export format.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sneddon-atom-export-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

I wrote this fairly quickly a few weeks ago in the middle of the  
night, and the more I look at it now, the more I see issues with it.  
Nevertheless, the basic structure of it is what I was generally  
thinking of all those months ago when speaking to Andrew. All the  
same, comments are welcome (though don't bother rushing thinking it is  
absolutely urgent: I doubt I'll do much more to it until June).

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: John Panzer <[email-masked]>
Date: Wed, 25 Mar 2009 22:48:45 -0700

Note: Blogger exports and imports blogs in an extended Atom format; we'd 
be interested in standardizing (the main extension is keeping comments 
with entries, and efforts have been made to re-use existing standards).  
Let me know if you want details.

---

From: Geoffrey Sneddon <[email-masked]>
Date: Thu, 26 Mar 2009 20:07:26 +0000

Removing Andrew seeming his email bounces…

On 26 Mar 2009, at 05:48, John Panzer wrote:

> Note: Blogger exports and imports blogs in an extended Atom format;  
> we'd be interested in standardizing (the main extension is keeping  
> comments with entries, and efforts have been made to re-use existing  
> standards).  Let me know if you want details.

Right, I had a look at what you guys did. My main issue was making  
certain values of atom:category significant, which seems a rather  
dirty hack (for a start, if you try and interpret it as a normal Atom  
feed document, you get something you don't want). Furthermore, it  
means that if an object has to be created for a Post/Comment, it  
couldn't be done (nor processing really beginning) until the  
atom:entry end tag had been seen, which makes processing a lot more  
complex using a streaming parser (which, as export files can easily  
become large, is needed).

The two nicer solutions I can think of are to either place atom:entry  
within a child element of atom:feed if it is a comment (but this falls  
into integration issue with things like atom:entry's atom:author  
coming from atom:feed or not, etc.), or to add an attribute to  
atom:entry (but this again has issues when the processor isn't aware  
of the export format, but has the possibility of being backwards  
compatible with Blogger).

Needless to say, all of these solutions have downsides, which is why I  
went with the ustar-based solution (which has it's downsides too, such  
as greater implementation complexity, but it has the advantage of  
being able to store other files apart from what can be easily put  
within the Atom feed).

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: Peter Keane <[email-masked]>
Date: Thu, 26 Mar 2009 15:34:24 -0500

On Thu, Mar 26, 2009 at 3:07 PM, Geoffrey Sneddon
<[email-masked]> wrote:
>> be interested in standardizing (the main extension is keeping comments with
>> entries, and efforts have been made to re-use existing standards).  Let me
>> know if you want details.
>
> Right, I had a look at what you guys did. My main issue was making certain
> values of atom:category significant, which seems a rather dirty hack (for a
> start, if you try and interpret it as a normal Atom feed document, you get
> something you don't want). Furthermore, it means that if an object has to be
> created for a Post/Comment, it couldn't be done (nor processing really
> beginning) until the atom:entry end tag had been seen, which makes
> processing a lot more complex using a streaming parser (which, as export
> files can easily become large, is needed).

Just wanted to mention that some folks (myself included) regard using
atom:category the way blogger does (to say this is a "comment" kind of
thing, or a "post" kind of thing) to be both perfectly appropriate and
actually elegant (not a "dirty hack").  The fact that they don't use
@label makes it trivial to have the category not display in
environments where it shouldn't.  I regard this sort of use of
atom:category one of the very best implementation practices for gently
& reasonably extending Atom.  Much of Atom's power comes from this
sort of thing. I realize that not everyone agrees :-).

--peter keane

>
> The two nicer solutions I can think of are to either place atom:entry within
> a child element of atom:feed if it is a comment (but this falls into
> integration issue with things like atom:entry's atom:author coming from
> atom:feed or not, etc.), or to add an attribute to atom:entry (but this
> again has issues when the processor isn't aware of the export format, but
> has the possibility of being backwards compatible with Blogger).
>
> Needless to say, all of these solutions have downsides, which is why I went
> with the ustar-based solution (which has it's downsides too, such as greater
> implementation complexity, but it has the advantage of being able to store
> other files apart from what can be easily put within the Atom feed).
>
> --
> Geoffrey Sneddon
> <http://gsnedders.com/>
>
>

---

From: "James Holderness" <[email-masked]>
Date: Fri, 27 Mar 2009 15:52:11 -0000

Peter Keane wrote:
> The fact that they don't use @label makes it trivial to have the
> category not display in environments where it shouldn't.

I'm not sure I understand what you're suggesting here. In which environments 
should categories without labels NOT be displayed? Would you consider a feed 
reader such an environment?

If so, are you suggesting that existing feed readers be rewritten to follow 
this new rule? And would feed publishers with simple term-only categories 
now need to add labels to all those categories in order to have them 
displayed in these newly-rewritten feed readers?

That sounds like an awful lot of pain for what you regard as an "elegant" 
solution. Is "elegant" maybe slang for "dumbest idea ever"?

Regards
James

---

From: Peter Keane <[email-masked]>
Date: Fri, 27 Mar 2009 11:25:20 -0500

> solution. Is "elegant" maybe slang for "dumbest idea ever"?

I actually hardly ever think of the case of feed readers when I think
about Atom, oddly enough.  Since the spec says: The "label" attribute
provides a human-readable label for display in end-user applications.
(4.2.2.3)" I was assuming that was its actual role in the wild.

I may be a party of one on this point (though I don't think so), but
for my uses of Atom (essentially in the SynOA style [1]),
atom@category is perfect for the sort of machine processing that I am
likely to do with an entry or feed.  And I have never had any problem
using a reader to monitor application processing, etc.  Inability to
use a stream processor is an obvious issue which I have not confronted
since I use DOM processing and a factory method that hands me the
correct entry object based on the atom:category of interest.

--peter

[1] http://www.oreillynet.com/xml/blog/2007/09/synoa_what.html

---

From: "James Holderness" <[email-masked]>
Date: Sat, 28 Mar 2009 14:48:05 -0000

Peter Keane wrote:
> about Atom, oddly enough.

Yeah, I can see that. I really would encourage you to spend a little time 
using a few of these feed readers and exploring their capabilities before 
you start proposing "best practices" that would cripple their functionality.

Regards
James

---

From: Peter Keane <[email-masked]>
Date: Sat, 28 Mar 2009 10:09:41 -0500

> you start proposing "best practices" that would cripple their functionality.

Does the Blogger format (which I was championing) cripple their
functionality?  Just curious....

--peter

---

From: Peter Keane <[email-masked]>
Date: Sat, 28 Mar 2009 12:36:38 -0500

> you start proposing "best practices" that would cripple their functionality.

Just checked my feeds in NetNewsWire, Liferea, and Google Reader & all
worked beautifully (I generally just use Firefox & check them in
FeedValidator).  Maybe we have different definitions of crippled?

--peter

---

From: John Panzer <[email-masked]>
Date: Sat, 28 Mar 2009 11:30:57 -0700

So people can see what we're talking about easily, I exported a (test) blog
and uploaded the xml here:

http://www.johnpanzer.com/blogexport.xml

Unfortunately this one didn't have comments, and only two entries, so most
of the data is taken up with settings.  If you view it in a feed reader, you
get something that looks a bit like key-value pairs (where each entry is a
key with a description and the content is the value).  There are various
drawbacks to the format, I'm not proposing it as a defined standard, but we
needed something to allow for export and import and it's an (IMHO)
reasonable starting point.

Looking at it in a reader, it's pretty clear that critical information isn't
being picked up by the generic reader, but it degrades fairly gracefully I
think.

John