Subject: Embedding microcontent in an Atom feed

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

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

I have a question about embedding multiple bits of information (each of
which can be represented in XML and has its own mime-type) in a single
Atom entry. An example might be that I have an entry describing some
up-coming exhibition and I also have a number of dates for it. I would
like to encode the descriptive part as XHTML and the dates in some (TBD)
XML encoding, lets postulate a text/vcalendar+xml.  This scenario arises
from an interest in building more intelligent aggregators, or maybe
plug-ins to augment existing aggregators. For example the aggregator
might be able extract particular mime-types from an entry and present
them in a different way from a standard 'news' aggregator. For example
'event' information might be presented in a calendar-like view.

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. Atom consumers (like my hypothetical aggregator)
SHOULD look at all alternative content elements and determine which one
is most suitable, based on which @type and @mode the consumer supports,
and preferences specified by the end user (if any). Consumers SHOULD NOT
render more than one content alternative.

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? 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. Does anyone have a scenario where this is employed?
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'.

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.

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. However the need to publish what is
conceptually one entry in multiple places does not seem attractive.
Indeed any ability to consume different types of what I would call
'microcontent' needs to be matched by an ability to easily author and
publish such content. Much blogging software doesn't provide for a way
to publish multiple content elements in an entry.

Maybe I approaching this the wrong way. 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. Can anybody point me in the right direction?

Regards

Adrian

http://adriancuthbert.blogspot.com/2004/08/questions-about-embedding-microco
ntent.html