Subject: Tools not supporting atom:content with @src ?

From: Peter Krantz <[email-masked]>
Date: Wed, 10 Jun 2009 00:42:09 +0200

Hi!

We are using Atom to get notifications about PDF documents added to
collections at various government agencies. This works well since we
are consuming the feeds programatically. A typical entry looks like
this (please note the atom:content element):

<entry>
   <id>tag:example.com,2009:1</id>
   <updated>2009-05-13T18:30:02Z</updated>
   <published>2009-05-13T18:30:02Z</published>
   <title>A title</title>
   <summary>A summary</summary>
   <content src="/docs/example.pdf" type="application/pdf" />
</entry>

It would be nice if the same feeds could be used in popular
feedreaders too. I have tried feeds with entries like the one above in
IE8, Firefox 3.5b4, Google Reader and Safari 4 but none of them make
it possible to access the PDF specified in the atom:content element.

Is this a misunderstanding on my part or is it just a rare enough
example that hasn't been implemented in client software?

Regards,

Peter Krantz

---

From: Erik Wilde <[email-masked]>
Date: Tue, 09 Jun 2009 15:54:02 -0700

hello peter.

> example that hasn't been implemented in client software?

i guess your example is perfectly ok, but none of the major feed readers 
really excel at implementing every possible combination of atom elements 
and features. for exmaple, another thing that bothers me in the browser 
implementations is that in firefox, if there is a summary, you will not 
see the content at all, which is pretty annoying. in safari, if there is 
summary and content, you won't see the summary... generally speaking, 
making assumptions about how exactly feed readers are going to display 
something is kind of risky, so the safe thing to do would be to have a 
short content with HTML linking to the PDF for humans, and to also have 
an entry/link pointing to the PDF as a rel="alternate" representation. i 
think this is the way that is most likely to work in feed readers.

cheers,

dret.

---

From: Martin Atkins <[email-masked]>
Date: Tue, 09 Jun 2009 17:39:18 -0700

> example that hasn't been implemented in client software?

I believe that this is valid, but in practice your average feed reader 
only implements the featureset of RSS, ignoring the more esoteric 
features of Atom. This is often because the parsing code started off as 
an RSS parser and had Atom bolted on, so there was no room in the API 
for some of Atom's unique features.

In practice, you're probably better off with something like the following:

<entry>
     <id>tag:example.com,2009:1</id>
     <updated>2009-05-13T18:30:02Z</updated>
     <published>2009-05-13T18:30:02Z</published>
     <title>A title</title>
     <summary>A summary</summary>
     <content>
         &lt;a href="/docs/example.pdf"&gt;Download PDF&lt;/a&gt;
     </content>
     <link rel="enclosure"
           href="/docs/example.pdf"
           type="application/pdf" />
</entry>

The link in the content will provide an access method for the most basic 
clients and the enclosure may provide additional functionality such as 
automatic download for clients with support for enclosures.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 09 Jun 2009 17:50:48 -0700

hello martin and peter.

> automatic download for clients with support for enclosures.

now that you say it, it may be the case than "enclosure" is the better 
way to go in this case. however, "enclosure" (i think) implies that the 
enclosure *is* the actual content. "alternate" says (i think) that the 
linked resource is an alternate version. and since you're publishing 
PDF, which is not the pinnacle of accessibility anyway, you might 
consider publishing all or some of the contents in HTML, in which case 
"alternate" might become more appropriate. this is what we did in our 
example for the stimulus feeds (which are currently distributed as excel 
files): we suggested to publish them as XML; and to make it even easier 
for humans to understand what's going on, we also publish them as HTML 
in the feed, and link to the XML from the feed via entry/link *and* from 
the embedded HTML. here is an example:

http://isd.ischool.berkeley.edu/stimulus/feeds/weekly-site.atom

it was my understanding that "alternate" would be the more appropriate 
relationship in this case, because the HTML and the XML are essentially 
the same, but the definitions of the relationships in atom leave some 
room for interpretation, i suppose.

cheers,

dret.

---

From: Peter Krantz <[email-masked]>
Date: Wed, 10 Jun 2009 09:39:57 +0200

On Wed, Jun 10, 2009 at 02:39, Martin Atkins <[email-masked]> wrote:
> [...]

But this implies that the actual content is "<a href..."?

Oh well. Maybe there could be an appendix some day with
recommendations on how to present Atom in user agents?

Regards,

Peter

---

From: Ross Singer <[email-masked]>
Date: Wed, 10 Jun 2009 20:32:59 -0400

Out of curiosity, why isn't your entry/id the http URI of your PDF document?

It seems like you could then have some description in your summary (or
anything, really) and pretty much any feed reader would make the title
linkable to the PDF.

That seems like the fewest hoops to jump through for maximum feed
reader support.

-Ross.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 11 Jun 2009 09:47:23 +0200

> anything, really) and pretty much any feed reader would make the title

I hope not!
Repeat after me: entry/id is *not* a link, it's just an ID that
happens to have the form of an URI.
(this is different from RSS when the ID can be --defaults to?-- the "permalink")

<link rel="alternate" href="..." /> would obviously work as you
describe (and has already been proposed in this thread)

-- 
Thomas Broyer

---

From: Ross Singer <[email-masked]>
Date: Thu, 11 Jun 2009 09:11:28 -0400

Wasn't the question how to make this work with popular feed readers?

Is anything I wrote not true in that regard?

Also, what argument are you making against using the http URI the
identifier?  I understand if the tag URI is necessary for internal
reasons for the application, but if the http URI is, indeed, a viable
identifier for the resource... why not use that?

-Ross.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 11 Jun 2009 16:59:20 +0200

> Is anything I wrote not true in that regard?

I *hope* feed readers do not use entry/id as a permalink (in the
absence of any link); I don't know how popular feed readers actually
work (never tested).

> identifier for the resource... why not use that?

The problem is not really using the "permalink" as the entry
identifier, but using the identifier as a permalink!

-- 
Thomas Broyer

---

From: John Panzer <[email-masked]>
Date: Thu, 11 Jun 2009 09:41:42 -0700

Ross Singer wrote:
> ... what argument are you making against using the http URI the
If the http URL is a permanent identifier that will never disappear 
unless the resource itself does, and will never be reassigned to some 
different resource, then sure.  In practice it's very hard to guarantee 
this.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 11 Jun 2009 18:52:17 +0200

John Panzer a écrit :
> different resource, then sure.  In practice it's very hard to 
> guarantee this.
Well it goes quite beyond the persistence of the value. The atom:id is 
an opaque string, it's a IRI, not a URL. Bypassing the difference really 
breaks the spirit behind it.

Use atom:link for that.

- Sylvain

---

From: Erik Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 10:59:39 -0700

hello.

> different resource, then sure.  In practice it's very hard to guarantee 

it's not that hard to guarantee that it will never be re-assigned, and 
that's all it takes ("disappearing" is not something that can happen to 
the identifier, i guess you mean that it stops working because of some 
server or domain reorganization issues). if you encode the date into it 
as many publishing schemes do, for example, re-assignment becomes almost 
a non-issue. and it's ok if it stops working from the identifier point 
of view, all that's required is that it needs to provide identification 
properties.

cheers,

dret.

---

From: John Panzer <[email-masked]>
Date: Thu, 11 Jun 2009 21:32:19 -0700

An http URL is as good as any other URI as an opaque identifier, all
other things like permanence being equal.

On Thursday, June 11, 2009, Sylvain Hellegouarch <[email-masked]> wrote:
> If the http URL is a permanent identifier that will never disappear unless the resource itself does, and will never be reassigned to some different resource, then sure.  In practice it's very hard to guarantee this.
>
> Well it goes quite beyond the persistence of the value. The atom:id is an opaque string, it's a IRI, not a URL. Bypassing the difference really breaks the spirit behind it.
>
> Use atom:link for that.
>
> - Sylvain
>

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Fri, 12 Jun 2009 08:37:59 +0200

> other things like permanence being equal.
Of course it is, but the question wasn't about using a URL as a 
identifier, but using the identifier as the locator.

- Sylvain