Re: Posted PaceEnclosuresAndPix

[Danny Ayers <danny.ayers@xxxxxxxxx>]

On Wed, 05 Jan 2005 13:36:06 -0800, Tim Bray <Tim.Bray@xxxxxxx> 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