Questions about embedding microcontent in an Atom feed

Imagine I wanted to write a new type of aggregator that could extract microcontent from feeds and then present that content in a way different from a normal 'news' aggregator. For example I might want to allow people to include 'event' information in their feeds and have my aggregator provide a calendar-like view onto all the events it had encountered.

Does the Atom Syndication Format help me do that?

Lets make the simplifying assumption that there is some well-defined, commonly-used way of representing a calendar event in XML with its own mime-type (lets postulate text/vcalendar+xml). I want to include both this 'structured' microcontent as well as my usual 'unstructured' ramblings into a single entry. My question is how is such hybrid content supposed to be included in an Atom feed?

AFAICT entries in Atom may have multiple <content> elements. Thus you could include the calendar event information and the wordy bits in separate <content> elements, each with the appropriate type attribute. However my understanding of things I have read elsewhare (but I can't find them now so this may be madness <UPDATE> more below </UPDATE>) is that under such circumstances the aggregator should pick a single content element to deliver. A possible example might be an aggregator 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'. What it would do faced with 'text/vcalendar+xml' and 'application/xhtml+xml' is anybody's guess.

However the multiple <content> element route has other issues. For example I suspect most blog authoring software does not make it easy to deliver multiple content elements. Finally, even if they did, how does this approach handle the situation when the entry needs to reference a pair of calendar events? (or is the 'rel' attribute is available on the 'content' element?)

So I am driven to ask the question whether it is possible/legal/good manners to put structured microcontent directly into the XHTML content?

I have just found some words about consumers of Atom only rendering a single content element. However this is based on a content element with type 'multipart/alternative'. Taken from IETF Draft of the Atom Syndication Format:

If @type="multipart/alternative", @mode MUST NOT be specified, and content element MUST contain 1 or more content elements. These content elements MUST NOT specify @type="multipart/alternative" (i.e. only one level of nesting is allowed). Consumers 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.

Comments

Post a Comment

Popular posts from this blog

A Review of hReview

microformats may well represent a path from where we are today to the [lowercase] semantic web. If so, one of the first waypoints along such a path could be the emergence of aggregators capable of taking advantage of suitably marked-up content. Applying a 'microformat' approach to tagging, Technorati introduced the rel="tag" approach to marking-up tags. Technorati also supply the corresponding aggregation service, e.g. see posts tagged with microformat . Given this minimalist approach to tagging, the hReview specification comes as something of a surprise. It seems to represent a format developed independently of the environment in which it is most likely to be used. The rel="tag" approach makes a major, simplifying assumption. This is that the tag refers 'to a major portion of the current page (i.e. a blog post)' . I am assuming that it could apply equally to a blog entry in an RSS/Atom feed. Thus an aggregator can associate a tag with two p...
Read more

SmartLink

Image
In a previous post I tried to describe how I thought technologies like SmartTags and AutoLink ought to behave. With greasemonkey in Firefox I've been able to build a proof-of-concept demonstrator. For the moment I'm calling it Smart Tag/Auto Link. SmartLink is based upon the idea that content authors should mark-up content that can be 'smart-linked', using standard XHTML constructs. This has two advantages: it effectively provides an 'opt-in' mechanism for content providers it doesn't require 'magic' to identify what can be smart-linked and thus provides a much more extensible approach. of course there is one fairly major disadvantage: there isn't any suitably marked-up content out there, with the exception of some test posts I've put together for the purpose. Getting Started If you want to know a bit more about SmartLink then click here . Alternatively if you want to see how SmartLink behaves and you're using Firefox t...
Read more

Google I/O 2013

With Google I/O approaching it is time to start speculating... Last year the keynotes at Google I/O were very different in tone; the one for Android and the one for Chrome OS. It will be interesting to see if there is any big change this year, now that Sundar Pichai will - indirectly - have a role in both. Google's commitment to the web and the evolution of Chrome has taken them to an extraordinary place.  Soon it will be possible to develop apps using standard web technologies and deploy them to a wide range of environments; desktops running OS X, Linus or Windows as well as Chrome OS. There seems to be a genuine desire to get Chrome apps to play nice in their host environments, not just within the browser. For example the launcher that was part of Chrome OS now has a variant in some desktop environments. The Chromebook Pixel has a touch screen, so developing Chrome apps for a touch interface is clearly on the agenda. So isn't it about time for Chrome apps on Android...
Read more