Subject: more than one content element?

From: Pascal Philippe <[email-masked]>
Date: Wed, 12 Oct 2005 11:54:33 +0200

Hello,

I would like to try to understand why we can't have more than one
atom:content element within an atom:entry element. Could you give me 
the reason of this choice?

For example, in a web blog entry, I can have more than one components.
A web blog entry can be, as example, a picture (encoded in base64)
with a text. How can I represent this using the Atom syntax?

Thanks!!

Pascal

---

From: "James Holderness" <[email-masked]>
Date: Thu, 13 Oct 2005 08:29:48 +0100

> with a text. How can I represent this using the Atom syntax?

If you want the image to appear inline, you can include it as an HTML (or 
XHTML) img tag within the atom:content element. Alternatively, if it would 
be better represented as an attachment you can include it as an enclosure 
(an atom:link element with the rel attribute set to "enclosure").

Regards
James

---

From: Eric Scheid <[email-masked]>
Date: Thu, 13 Oct 2005 18:11:37 +1000

> the reason of this choice?

IIRC, it was thought it would be too burdensome for developers to cope with
the possibility, first detecting that there are multiple atom:content
elements, and then having to either choose one of the formats they support
or providing mechanisms for the user to select.

It would have been handy for a recent use case: in Switzerland, govt
announcements need to be made in three languages, simultaneously, and
without favour to any one language.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Oct 2005 11:19:31 +0200

* James Holderness <[email-masked]> [2005-10-13 09:40]:
> If you want the image to appear inline, you can include it as
> an HTML (or XHTML) img tag within the atom:content element.
> Alternatively, if it would be better represented as an
> attachment you can include it as an enclosure (an atom:link
> element with the rel attribute set to "enclosure").

And deviously, you can inline the image data inside the feed too,
by using a data: URI with one of these methods.

However, shipping blobs around inside a feed is not a bright idea
with the currently common feed use cases.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "James Holderness" <[email-masked]>
Date: Thu, 13 Oct 2005 11:05:16 +0100

> with the currently common feed use cases.

There's also the problem that Internet Explorer doesn't support data: URIs. 
And I suspect (although I may be wrong) that most client-side aggregators 
use IE functionality for their HTML display.

My other also-not-likely-to-be-supported suggestion if you really wanted to 
bundle a blob in your message would be to include an atom:content with a 
type of multipart/mixed or multipart/related. However I see that Atom 
explicitly disallows that. Anyone know the reason? Not that I have any 
desire to do such a thing - just curious.

Regards
James

---

From: John Panzer <[email-masked]>
Date: Thu, 13 Oct 2005 09:20:13 -0700

James Holderness wrote:

> There's also the problem that Internet Explorer doesn't support data: 
> URIs. And I suspect (although I may be wrong) that most client-side 
> aggregators use IE functionality for their HTML display.
>
> My other also-not-likely-to-be-supported suggestion if you really 
> wanted to bundle a blob in your message would be to include an 
> atom:content with a type of multipart/mixed or multipart/related. 
> However I see that Atom explicitly disallows that. Anyone know the 
> reason? Not that I have any desire to do such a thing - just curious.

If I recall, I believe this is because some people wanted to be able to 
package multiple pieces of content together in a single entry, and other 
people did not want to have to imply a requirement for MIME multipart 
parsing as pat of the Atom format specification.  So this was kicked 
over to the APP to handle as a series of posts using generic non-entry 
resources and links.

Me?  I just want to post cat pictures.

-John

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Oct 2005 19:14:19 +0200

* John Panzer <[email-masked]> [2005-10-13 18:45]:
> If I recall, I believe this is because some people wanted to be
> able to package multiple pieces of content together in a single
> entry, and other people did not want to have to imply a
> requirement for MIME multipart parsing as pat of the Atom
> format specification.

And in retrospect, I think this was a mistake. F.ex. a while ago
we had someone asking why he isn’t able to publish mailing list
archives as a feed with entries containing the original message
as a message/rfc822 payload, and indeed there’s no good reason
he can’t. He just can’t.

(This would have been a nice use case: stick the original message
into atom:content and put a version rendered as HTML into
atom:summary. I have to say I am liking this
atom:summary/atom:content dichotomy more and more with every
passing day.)

The right thing, I *think*, would have been for Atom Format to
say that an Atom processor MAY decode envelopes (translation:
don’t hold your breath), and for Atom Protocol to say the server
MUST NOT decode envelopes (translation: if I ship a
message/rfc822 payload, the server simply stores it as such).

As is, the only option is to stick the blob into an enclosure,
inlined though the backdoor by using a data: URI.

Regards,

---

From: John Panzer <[email-masked]>
Date: Thu, 13 Oct 2005 10:39:29 -0700

>inlined though the backdoor by using a data: URI.
Well, you can pass them around by reference with content@src.  I think.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Oct 2005 20:06:56 +0200

> Well, you can pass them around by reference with content@src.

By the letter of the spec, but not by the spirit.

But that’s beside the point, since if you’re going to point to an
external resource, you can and should use an enclosure for the
purpose, which has no restrictions on the content anyway.

The reasoning of the restriction regarding atom:content is to
avoid burdening Atom processors with having to decode MIME
envelopes. It wouldn’t make any sense to apply that only to
inline payloads, but not to remote content, since they are
semantically identical. So by spirit, the spec does not.

By letter, it doesn’t forbid it, because the type of
representation returned by the server when retrieveing remote
content is not realistically enforcable. Thus, the rules are

• If @src is present, then @type SHOULD also be.
• But @type MUST NOT be a composite type. Ever.
• However in the presence of @src, @type is only a hint.

That means you can omit the @type (and get complaints) or just
outright lie about it (and people will have to deal). In either
case, though, the consumer’s behaviour upon processing your feed
is undefined, so you don’t gain anything.

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Thu, 13 Oct 2005 12:47:38 -0600

> By the letter of the spec, but not by the spirit.

I just ran through the discussion of this very question on the  
mailing list[1], and though it looks like allowing composite types in  
remote content had pretty good support, that doesn't appear to have  
been translated into a Pace, and obviously, no language specifically  
allowing it got into the spec document.  Thus, it looks like the  
prohibition from section 4.1.3.1 stands, and that you're right that  
the only way you could do it without breaking the rules outright  
would be by ignoring the SHOULD (have content/@type when using  
content/@src), which would certainly be contrary to the "spirit" of  
the spec as it stands.

[1] http://www.imc.org/atom-syntax/mail-archive/msg15949.html

---

From: "James Holderness" <[email-masked]>
Date: Thu, 13 Oct 2005 22:09:19 +0100

> John Panzer wrote:

Ugh. Sometimes I just don't get these decisions. Since when does allowing 
something imply that it is REQUIRED? Following that reasoning, any MIME type 
that isn't expressly forbidden is now REQUIRED to be supported.

Of course that's insane. Implementers will decide which MIME types to 
support based on market needs, as has always been the case (cf. email 
clients and newsreaders). With Atom, however, composite MIME types have been 
(quite unnecessarily IMO) excluded from their list of choices.

> message/rfc822 payload, the server simply stores it as such).

Agreed. If you're worried about an implied requirement you can always add a 
warning: "Feed producers should be aware that Atom Processors may not 
process all such types. In particular an Atom Processor is not required to 
process composite types." Or something to that effect.

That way you've explicitly covered your ass while leaving the format open to 
the needs of the market. If a feed producer decided they absolutely had to 
use a composite type in the atom:content, a non-supporting processor could 
still fallback to the summary (since that is REQUIRED when the type isn't 
text or xml).

IMHO.

Regards
James