Aristotle Pagaltzis wrote:
* James Holderness <[EMAIL PROTECTED]> [2008-06-07 01:10]:
Aristotle Pagaltzis wrote:
As a publisher, yes. For authors of clients, particularly
^^^^^^^^^^^^^^^^^^^^^^
clients intended for a specific purpose, the extent to which
other existing clients fail to take advantage of the specified
features of the format is of little relevance.
Did you read what I wrote? :-)
Yeah, I realised how idiotic my response was *after* I posted it, but by
that point I was too tired out by my rant to post a followup. :)
What I should have said was that it's something of a chicken and egg
situation. There's not much incentive for clients to support features of
Atom that aren't actually used by anyone. And feed publishers are not going
to start using the features when they are so poorly supported by clients
(especially when using such a feature would have a negative impact on
readers).
Now, as you've said, there are certain things that may be worth doing (from
both a client and server point of view) even if they're not supported, as
long as doing so is not actively harmful. But I've been burned by this
before (on the client side) - I regret supporting remote image content,
given that the only feeds I've seen using it actually work better in
aggregators that ignore that content.
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.
To a large extent it depends on how clients are expected to treat this kind
of 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).
For example, look at the following example atom entries (some elements
omitted that aren't relevent to the discussion).
<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="html"><img src="eiffeltower.jpg"/></content>
</entry>
<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="image/jpeg">
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9...
</content>
</entry>
<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="image/jpeg" src="eiffeltower.jpg" />
</entry>
<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<link rel="alternate" type="image/jpeg" href="eiffeltower.jpg" />
</entry>
<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?
As a client author I really would like to know the answers to these
questions. It's all very well not wanting to constrain implementations, but
if you don't explicitly tell developers what to do, they tend to do nothing;
or they all do something different. Either way publishers have no way of
knowing what they're going to get, so they tend to stick with the tried and
trusted html, even if another choice may have been more appropriate.
Regards
James
