Loading ...
Sorry, an error occurred while loading the content.

Enclosures, multiple formats

Expand Messages
  • Danny Ayers
    [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
    Message 1 of 2 , Nov 27, 2004
      [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:

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

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

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

      rather than simply:

      ...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"/>

      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

      <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:length="16716621" enc:type="application/x-bittorrent"/>


      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


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


    • Danny Ayers
      A little update for rss-dev, some pointers from the Podcasting list relating to the RSS 2.0 approach to mp3+BitTorrent enclosures. I wasn t missing anything,
      Message 2 of 2 , Nov 27, 2004
        A little update for rss-dev, some pointers from the Podcasting list
        relating to the RSS 2.0 approach to mp3+BitTorrent enclosures. I
        wasn't missing anything, the proposal just takes a rather unexpected
        approach, creating a new namespace and term to support a single extra
        mime type.

        It seems the reasoning for not using multiple enclosure elements in an
        item is in part due to the /implication/ in the RSS 2.0 spec that an
        item will only have one <enclosure> element, also because: "I think
        when you go all the way down the multiple enclosures path you'll have
        completely reinvented the RSS item inside the enclosure (inside the
        item)." [1].

        (I don't actually think anyone was actually suggesting going "...all
        the way down the multiple enclosures path", just multiple elements
        when the same recording was available in different formats/mime types,
        i.e. mp3 and BitTorrent).

        Anyhow, here are some refs:

        David Janes -
        As you say, in this (http://blogs.law.harvard.edu/tech/rss) all elements
        that can be repeated (e.g. <item>) are explicitly marked as so. Also this
        (http://blogs.law.harvard.edu/tech/enclosuresAggregators) says "allows an
        item to have _an_ enclosure".

        Ross Wm. Rader points to

        which has an item containing multiple <enclosure /> elements.

        David Janes (re-)proposes using an additional link element *inside*
        the enclosure:
        url="http://.../sixteen.torrent" />

        Jerry Brown points to Ray Slakinski's <podcast:attachment> proposal,

        Turns out there is a comment space for Dave Winer's proposal:
        [1] http://www.ipodder.org/2004/11/26#a601


      Your message has been successfully submitted and would be delivered to recipients shortly.