Eric Scheid wrote:
The challenge with using alternate to point to files of different types
is that why would someone do (a) when they can already do (b) without
the help of a new extension
(a)
<link rel="enclosure" type="audio/mpeg"
href="http://example.com/file.mp3";>
<x:alternate type="application/ogg" href="http://example2.com/file.ogg";
/>
</link>
(b)
<link rel="enclosure" type="audio/mpeg"
href="http://example.com/file.mp3"; />
<link rel="enclosure" type="application/ogg"
href="http://example2.com/file.ogg"; />
With (a), we know the .mp3 and the .ogg are simply different formats of
the
same thing. With (b) we don't know either way.
I like (a) in concept because, as you say, it enables you to tell when two
links are the same so if you're auto-downloading you don't need them both.
However, I do think James is right in thinking that many people will just
use (b) because it's already there.
I don't see the harm in allowing (a) though. If a feed producer uses (a) and
an end-user has auto-downloading enabled for that feed, they both benefit
from less wasted bandwidth. The only downside would be that aggregators that
aren't aware of this extension would fail to see the alternate enclosures.
Is that so bad though? It's a trade-off the feed producer has to make - I'm
not sure we should be making that decision for them.
Something else that just occured to me: is there any likelyhood of this kind
of extension breaking existing aggregators? I know that technically there's
nothing wrong with it, but I can see aggregators that have home-grown XML
parsers possibly getting confused by this.
I'm not suggesting the proposal should be abandoned because of a few poor
implementations of the Atom spec, but I think it would be worth finding out
how much of a problem it is (if anything). Maybe run a test feed through a
few of the most popular aggregators and see how many explode.
The ones I've tested so far: neither FeedReader nor FeedDemon support
enclosures. I'm not sure if that's good news or bad news.
Regards
James
