On 14/01/2008, James Holderness <[EMAIL PROTECTED]> wrote: > > 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 bad for not being clearer. It's pretty much the latter. It's a little strange. We have had a variety of clients with their own custom XML formats that we've imported, some that provide RSS 2.0 plus their own extension modules and some that don't have an existing feed and are amenable to our input in terms of how the feed is structured. For now, the feeds aren't consumed by typical feed readers - mainly just our importing application (which imports the content and processes it into a form suitable for display on mobile devices) and other partners' applications that wish to process the feed. In order to re-use our importer code-base as much as possible, we'd like to offer the same Atom-based suggestion to current and future clients. That has the obvious benefits for my company in that I only have to write one client using Abdera / suitable Java library and we can then get away from writing custom importers for each client. It also has the desirable property that our client ends up with a feed that should be useful in other contexts, and isn't irrevocably tied to our solution; i.e. the client doesn't feel locked in. One of our clients is talking about using this format with all of their partners in an industry sector, hence my desire to use open standards, re-use existing extensions and avoid any custom extensions as much as possible. I think (maybe incorrectly) that it's more likely to appeal to a wider community within that industry sector if it's open, standards-based rather than a proprietary format that maps to our internal binary data structures. In summary, we already have a client which will process these feeds. I'm trying to define a suitable format for our upstream partners to produce. > > > 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. Maybe metadata is a bit misleading. I view it as metadata, but it's really just the attributes of the media entity. For images, this may be height, width, colour depth, etc. For video, this could be audio bitrate, video bitrate, frames per second, duration, etc. We could try extracting that ourselves, or we can rely on the author of the media entity knowing what it is and setting the corresponding attributes in the feed. > > 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. That's what my current draft looks like, so colour me happy. There are typically multiple versions of the same media entity, e.g the lost dog story video; provided in different formats to ensure good coverage of target client devices. Alternatively, there may only be a single version, and we produce lots of different versions as part of the import process. > > > 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 > > Thanks for your comments - very useful. I should have made my position clearer. Cheers, James
