On Wed, 05 Jan 2005 13:36:06 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > There are a couple of areas where we don't quite have feature parity > with RSS2.0, this tries to address that: > http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix -Tim
I could live with this Pace, feature parity and ease of migration being good justification for the approach. But - 1. If the media object is the primary content of the entry (which seems to be the main use case for RSS 2.0's <enclosure>), shouldn't it be delivered using some form of the <content> element? 2. Without multiple rel="enclosure", how does support and differentiate between media objects that are essentially the same resource but different formats, where the difference may not (easily) be expressed using mime types? Example: "Tim's award acceptance speech" (pretty good quality: mp3, 16bit, stereo, 44.1kHz 128Kbit compression) "Tim's award acceptance speech" (for saddos like danny with dialups: mp3, 12bit, mono, 11.025kHz 56Kbit compression) 3. I don't think this Pace is the right place for listing what should go in the <link> registry - separation of concerns and all that 4. What do we call an inline (i.e. base64 encoded content) media object - an attachment? Cheers, Danny. -- http://dannyayers.com
