Subject: Re: Embedding microcontent in an Atom feed

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 03 Sep 2004 18:58:01 +0200

On Thu, 26 Aug 2004 18:30:55 +0100, Adrian Cuthbert  
<[email-masked]> wrote:

> I am new to this mailing list so please forgive me if the question is not
> pitched at the correct level.

The only thing «bad» about your question(s) are the timing and length of  
the e-mail. But there's nothing wrong with that, it's just that we have a  
lot on our minds right now. ;-)

> My understanding of the Atom Syndication Format is that entries may have
> multiple content elements, each with its own @type. If a content element
> has a  @type of 'multipart/alternative' then there can only be a single
> level of nesting.

That's correct. But there is almost (but not quite) consensus that  
'multipart/*' should be removed, and replaced with another simpler  
solution. What consensus is halted on, is that accessibility might be hurt  
if we remove it.

> Is there a real difference between having multiple content elements each
> with its own non-multipart @type and haveing a single content element
> with a multipart @type and a single level of nesting?

Yes. Without 'multipart/*', you don't say anything about the atom:content  
element's relation. 'multipart/alternative' says that all child  
atom:content elements are alternative representations of one another.

'multipart/related' says that child atom:content elements are related in a  
way, and could probably mean the same as not having 'multipart' at all.  
E.g., one could perhaps consider the following examples semantically  
equivalent:

   <entry>
     <content type="multipart/related">
       <content type="image/jpeg" src="..." />
       <content type="text/plain">
         <![CDATA[ ... ]]>
       </content>
       <content type="application/xhtml+xml">
         <h1>Hi</h1>
       </content>
     </content>
   </entry>

   ...

   <entry>
     <content type="image/jpeg" src="..." />
     <content type="text/plain">
       <![CDATA[ ... ]]>
     </content>
     <content type="application/xhtml+xml">
       <h1>Hi</h1>
     </content>
   </entry>

> If there is no difference then presumably the restrictions on consumers
> that apply to content elements with a multipart @type also apply to
> consumers of entries with multiple content elements, ie they should look
> at them all but only render one.

True. Baking MIME into Atom is complicated. And it doesn't solve all  
challenges we have with relating content elements either, so I'm not sure  
it's the greatest solution. I'm not sure which solution is, though.

> A possible example might be a consumer that is delivering to a mobile
> device with limited capabilities. Under such circumstances content of
> @type 'text/plain' might win out over content with @type
> 'application/xhtml+xml'.

Yes, and for accessibility purposes, textual content will always win over  
visual.

> This would seem to indicate that there is no sensible way to include
> content with @type 'text/vcalendar+xml' and @type
> 'application/xhtml+xml' in the same entry, since I cannot see how a
> consumer could be expected to choose between the two.

Then you wouldn't use 'type="multipart/alternate"'. You would probably not  
use MIME multipart at all, but just squeeze all atom:content elements in  
as children of atom:entry.

> Of course an alternate approach would be to use link elements to point
> to the 'event' information and use @rel to identify special types of
> information to the consumer.

That sounds a bit like a hack to me. It would probably be better to use  
the semantically richer and more correct atom:content. Especially when or  
if we get atom:content/@src into the specification, that would be a good  
solution for any type of content.

> However the need to publish what is conceptually one entry in multiple
> places does not seem attractive.

Indeed.

> My interest is in Atom's extensibility, specifically an ability to
> publish entries which contain specialist types of microcontent and
> then have Atom consumers able to extract that microcontent and present
> it in a way best suited to its specialist nature.

Your interest is appreciated, and I hope I have managed to answer some of  
your questions.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»