Re: more than one content element?
Pascal Philippe wrote: 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? 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
Re: more than one content element?
On 12/10/05 7:54 PM, Pascal Philippe [EMAIL PROTECTED] wrote: 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? 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.
Re: more than one content element?
* James Holderness [EMAIL PROTECTED] [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/
Re: more than one content element?
A. Pagaltzis wrote: 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. 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
Re: more than one content element?
James Holderness wrote: A. Pagaltzis wrote: 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. 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
Re: more than one content element?
* John Panzer [EMAIL PROTECTED] [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, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: more than one content element?
A. Pagaltzis wrote: * John Panzer [EMAIL PROTECTED] [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. Well, you can pass them around by reference with [EMAIL PROTECTED] I think. Regards,
Re: more than one content element?
* John Panzer [EMAIL PROTECTED] [2005-10-13 19:40]: Well, you can pass them around by reference with [EMAIL PROTECTED] I think. 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, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: more than one content element?
On Oct 13, 2005, at 12:06 PM, A. Pagaltzis wrote: * John Panzer [EMAIL PROTECTED] [2005-10-13 19:40]: Well, you can pass them around by reference with [EMAIL PROTECTED] I think. 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
Re: more than one content element?
John Panzer wrote: 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. 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. A. Pagaltzis wrote: 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). 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
more than one content element?
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
