* James M Snell <[EMAIL PROTECTED]> [2005-10-22 17:20]: > (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"; />
* Antone Roundy <[EMAIL PROTECTED]> [2005-10-24 18:10]: > (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" /> > > (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> 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. Specifying alternative formats with a distinct link relationship prevents bandwidth and diskspace drain from oblivious clients. And once you’ve gotten so far as to think of one enclosure as the preferentially advertised format, it’s no stretch to think of grouping alternative-format enclosures as linking the alternative format enclosures to the preferrentially advertised one. And that’s a purpose for which IDs work just fine. Thinking in terms of code I believe this model is a bit easier to process than any of the alternatives. A list of mirror URLs is obviously trivial to retrieve. And just as you can do with the nested-element models, you can read the list of enclosure groups right off the markup simply by looking for any `enclosure` links. But less nesting is easier to process. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
