James Abley wrote:
The background for this request is that my company helps our partners deliver content on mobile internet platforms. We are trying to guide our partners into producing a common feed format that can be easily re-purposed and doesn't require specialist tools to handle.
When you say "doesn't require specialist tools", does that mean you would like the feed to work with a typical feed reader? Or are you only worried about generating the feed with a general purpose tool (like say Abdera) but expect a specialist client to read the feed?
If the former, I think you're going about this the wrong way. If the latter, you can ignore the rest of this message.
My initial problem - meta-data ------------------------------------------- I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which should cover that.
Exactly what kind of metadata do you need? If you just want to assign metadata to the feed entries then there's not that much that Yahoo Media gives you that isn't already in Atom (author, description, category, etc.). If your worry is that you need to include multiple media enclosures with each entry and want to provide separate metadata for each enclosure then you have much bigger problems.
Support for multiple Atom enclosure links is fairly poor in current feed readers, but there is at least some support. Support for Yahoo media:content elements in Atom is non-existent (AFAIK). Your best bet for adding metadata to multiple enclosure elements would be as sub-elements of a standard atom:link element. That still requires a specialist client to view the metadata, but at least the media itself might be accessible to a general purpose reader.
Next problem - content expiry ------------------------------------------- Predominantly I think this is required for news agencies, so that they have control over what gets displayed downstream. My initial ideas, seemingly confirmed by the archives, are for one of the following:
As long as those news agencies are aware that they really have no control over what gets displayed downstream. It doesn't matter what option you choose, nearly all general purpose feed readers will ignore it. The only hope of having any control like this would be with some form of encryption and a proprietary client (something like DIVX perhaps).
Final problem (for now!) - editorial control / lead articles ------------------------------------------------------------------------------- Certain content producers have indicated that they need to be able to define importance on a feed entry; e.g. the story about the US election should be treated as the lead story, and the story about someone's lost dog is the "...and finally..." story that we can put at the bottom of a page.
I would go with a category element as James Snell suggested. That would at least have some value in a general purpose feed reader.
Related subject - having multiple images for an item, with different semantics on the images; e.g. this one is the image related to the story subject matter; e.g. picture of Presidential candidate; this one is the headshot of the columnist that authored the story. For that, along with the extension element / RDF / Dublin Core options, I have the added choice of using a (non-official) link relation extension.
I don't get what you're trying to do here. Why don't you just include the images in the (x)html of the content element, laid out in some way that would look good to a regular feed reader. If you need the metadata for use in a specialist client, come up with your own microformat (class attributes on the img elements). That should make it easy for the client to do a more fancy layout with CSS or even extract the images from the markup if necessary.
Bottom line: if you want these feeds to be useful (not just barely functional) to a typical feed reader you need to be thinking how you can use standard Atom elements as much as possible. Extensions should be a last resort when all else has failed.
Regards James
