* James Holderness <[EMAIL PROTECTED]> [2008-06-07 13:55]: > Aristotle Pagaltzis wrote: >> You get a MIME type. You can do what mail clients do. That’s a >> lot for free. >> >> With RSS, all you get is a namespace URI. How useful. > > Funny you should mention that. When I was looking at that DOAP > example from earlier I was just thinking how useless the MIME > type was, and how the only way you could interpret that content > usefully was by looking at the namespace. :) In general you > might have a point though.
This is a problem with RDF in general. That DOAP-over-Atom is the only easily visible example of non-HTML content in feeds (that I know of anyway) is unfortunate in that respect. The point is, if someone shipped PDFs via a feed, say, then a client has all the information and the system mechanisms it needs to do something useful with that content. > Atom could really have used some guidance for implementors in > this area IMHO. If you look at the mail specs (in particular > the MIME stuff), they're actually quite explicit about what > implementors should do (without be overly stringent). Completely agreed. Shades of an implementor’s guide… > For example, look at the following example atom entries (some > elements omitted that aren't relevent to the discussion). > #1 > <entry> > <summary>A photograph of the Eiffel Tower.</summary> > <content type="html"><img src="eiffeltower.jpg"/></content> > </entry> > #2 > <entry> > <summary>A photograph of the Eiffel Tower.</summary> > <content type="image/jpeg"> > /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9... > </content> > </entry> > #3 > <entry> > <summary>A photograph of the Eiffel Tower.</summary> > <content type="image/jpeg" src="eiffeltower.jpg" /> > </entry> > #4 > <entry> > <summary>A photograph of the Eiffel Tower.</summary> > <link rel="alternate" type="image/jpeg" href="eiffeltower.jpg" /> > </entry> > #5 > <entry> > <summary>A photograph of the Eiffel Tower.</summary> > <link rel="enclosure" type="image/jpeg" href="eiffeltower.jpg" /> > </entry> > > What exactly is the difference between each of them? Assuming a > client is capable of displaying jpeg images, what *should* it > do with each of those entries? Assuming it *wasn't* capable of > displaying images, what should it do with them? Is the latter > case different for a client that doesn't display images for > accessibility reasons? In #1 the content is HTML. The summary semantically is not alternative content for the image, it is for the HTML content as a whole, which might consist of more than just an image and in this case just happens not to. Any fallback for the image in non-image-capable aggregators would have to happen at the HTML level, ie with an `alt` attribute. Entries #2 and #3 are identical: the content is an image, so the summary applies to the image specifically. The image should be shown in contexts where the full content is shown, and if it cannot be, then the summary should stand in. In case #4 I would expect an aggregator to show just the summary along with a link to the image. Some aggregators that allow loading the permalink page when you click on an item, instead of showing in the in-feed content; those would probably try to load the image, in which case they would treat it just like a browser. With #5 I would expect the summary to be shown, with the image downloaded to some directory of the user’s choosing if the user has so configured their reader, and some kind of attachment feature to be provided for viewing the downloaded content. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
