One enclosure per item or multiple?
Over the years one of the criticisms of RSS 2.0, the version of RSS that enabled podcasting, is that it only allowed one enclosure per item.
by Dave Winer Sunday, May 21, 2017

Over the years one of the criticisms of RSS 2.0, the version of RSS that enabled podcasting, is that it only allowed one enclosure per item.

This was a deliberate decision. I was aware at the time that there was a choice. I went with the one-to-one correspondence. There were two reasons, a design question and to keep it simpler for developers and podcast listeners.

  1. Suppose you allowed an arbitrary number of enclosures. Wouldn't you want to be able to describe each? If so, an enclosure would morph from being a simple three-attribute element, to a structure. What would be the new sub-elements? One obvious one would be <description>. How about a title? A date? Category? Author? I'm sure you see where this is going. We just created a new <item> inside an enclosure. And could an enclosure have an enclosure? Why not? Isn't that more powerful? (The reason usually given for having more enclosures.)
  2. The second reason is that you made life more complicated for the aggregator developer. When they look for an enclosure they somehow have to decide which of the multiple enclosures the user wants, or offer a choice to the user. Does the user really care what format the podcast is in? When I'm listening what I want is to hear the podcast. You want me to choose? My life is already too complicated. Too much software interrupts the flow of my thought with questions I have no interest in.