[apologies for crossposts, I'm not sure which list deals with RSS 2.0
technical issues]

There's a use case for multiple formats that's being defined for RSS
2.0 which mod_enclosures for RSS 1.0 should also be able to handle -
publishing the same data as mp3 over HTTP or as a BitTorrent stream.
An approach has be proposed for RSS 2.0 [1] which seems a little
strange to me. I realise this itself is out of scope on rss-dev, but I
may be missing something obvious that would impact any RSS 1.0
enclosure module.

Ok, the decision has been made to be explicit about the media type in
the XML rather than using HTTP negotiation. That seems reasonable
enough. Here's an RSS 2.0 item with a single enclosure:

<item>
...regular item elements...
<enclosure url="http://adam.opml.org/DSC20041124.mp3"
length="16716621" type="audio/mpeg"/>
</item>

What I don't understand is when it comes to multiple alternate types,
the proposal for RSS 2.0 suggests:

<item>
...regular item elements...
<bitTorrent:torrent
url="http://torrents.podcatch.com/DSC20041124.mp3.torrent"/>
<enclosure url="http://adam.opml.org/DSC20041124.mp3"
length="16716621" type="audio/mpeg"/>
</item>

rather than simply:

<item>
...regular item elements...
<enclosure url="http://adam.opml.org/DSC20041124.mp3"
length="16716621" type="audio/mpeg"/>
<enclosure url="http://torrents.podcatch.com/DSC20041124.mp3.torrent"
length="16716621" type="application/x-bittorrent"/>
</item>

Doesn't the latter make a lot more sense?

Moving on to RSS 1.0, I have a question following the mod_enclosures
proposals so far: is there much/anything to be gained by wrapping
multiple enclosures in an container? After all, the enclosures are all
associated with the same rss:item, isn't that enough? The advantage
here would be ease of implementation, as there's no need to follow Alt
paths or whatever.

For a single enclosure in abbreviated syntax, it would be identical to
the RSS 2.0 version, with the exception of namespace qualification
(whether alternate RDF/XML serializations should be allowed is another
matter, one for later I'd say). For enclosures of multiple types, you
have:

<item rdf:about="http://example.org/sdf">
...usual elements...

<enc:enclosure enc:url="http://adam.opml.org/DSC20041124.mp3"
enc:length="16716621" enc:type="audio/mpeg"/>

<enc:enclosure
enc:url="http://torrents.podcatch.com/DSC20041124.mp3.torrent"
enc:length="16716621" enc:type="application/x-bittorrent"/>

</item>

Which makes sense in the RDF graph. This would assume that only one
set of enclosure content (of multiple mime types) was associated with
each item, but that seems a reasonably sensible restriction anyhow -
if the content is different at the 'human' level, then wouldn't it be
appropriate to associate it with a separate rss:item?

This approach should be straightforward to implement by publishers and
consumers, whether they only look at XML or can correctly interpret
the RDF. There's still the opportunity to add rich metadata where
systems are RDF-capable (e.g. describe the person speaking with FOAF
or copyright information with Creative Commons), either by decorating
the rss:item with further properties or pulling out the enclosure URIs
and using them as the subject of further description (i.e. in
rdf:about).

Cheers,
Danny.

[1] http://www.reallysimplesyndication.com/bitTorrentRssModule

--

http://dannyayers.com