On Oct 24, 2005, at 1:48 PM, A. Pagaltzis wrote:
I have a completely different proposition.
(e)
<link
rel="enclosure" type="audio/mpeg"
href="http://example.com/file.mp3"
encl:mirrors="http://www2.example.com/file.mp3 http://
www3.example.com/file.mp3"
xml:id="x-file"
/>
<link
rel="alternative-enclosure" type="application/ogg"
href="http://example2.com/file.ogg"
encl:alternative-to="x-file"
/>
Since bit-for-bit identical files all have the exact same
attributes, there is absolutely no reason to have an entire tag
dedicated to each. In addition, making mirror URLs second-class
citizens in this ways provides an intuitive hint at the
bit-for-bit identity semantics.
Interesting. Filling an attribute with a list of URIs doesn't really
appeal to me though. How about this:
<link rel="enclosure" type="audio/mpeg" href="http://example.com/
file.mp3" xml:id="x-file">
<altlink:mirror href="http://www2.example.com/file.mp3" />
<altlink:mirror href="http://www3.example.com/file.mp3" />
</link>
Specifying alternative formats with a distinct link relationship
prevents bandwidth and diskspace drain from oblivious clients.
Sounds good, but you may have noticed above that I used a prefix not
specific to enclosures--there's no reason to tie this all to one
particular type of link (nor to make it look as if it were tied to
one specific link type). So the other link might, for example, be:
<link rel="alternative-link" type="application/ogg" href="http://
example2.com/file.ogg" altlink:primary="x-file" />
Although "alternative-link" doesn't tell you what kind of link this
is, since you're going to have to tie it back to the primary link to
decide what to do with it anyway, it really shouldn't matter. Note
that I changed "alternative-to" to "primary" just because it's
shorter and one word.