On Oct 24, 2005, at 5:18 AM, James Holderness wrote:
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.
Here's the middle path:
(c)
<link rel="enclosure" type="audio/mpeg" href="http://example.com/
file.mp3" x:link-set="a" />
<link rel="enclosure" type="application/ogg" href="http://
example2.com/file.ogg" x:link-set="a" />
This won't save you from bandwidth waste by aggregators that don't
support the extension, but it also won't prevent users of those
aggregators from getting the data in a format they can use. That
said, this is not my preferred method. I'd rather protect bandwidth
and the user's hard drive space--all the more important because
enclosures are often quite large.
Here's a final option--is it legal? Is it better or worse than (a)
in any ways?
(d)
<link rel="enclosure" type="audio/mpeg" href="http://example.com/
file.mp3">
<link rel="alternate" type="application/ogg" href="http://
example2.com/file.ogg" />
</link>
Better: Doesn't require processing of a new namespace or element--
just a new way of using the data that one gets out of an existing
element.
I prefer d, a, c and then b.