One of the biggest debates in RSS-land is multi-enclosures. How do you do them? Can an item have more than one enclosure? How do I include enclosures in multiple languages? multiple formats? Trying to gain consensus on this issue is like trying solve the Iraqi civil war. It may take a generation. So, your best bet is to get all the cards on the table and make the best decisions with what we have.
The best place to start is the spec text. The spec doesn't really say to much. Under <item> it says "All elements of an item are optional, however at least one of title or description must be present" and lists enclosure as one of the optional child element with the description "Describes a media object that is attached to the item." Then under <enclosure> the complete text follows in the block quote.
<enclosure> is an optional sub-element of <item>.
It has three required attributes. url says where the enclosure is located, length says how big it is in bytes, and type says what its type is, a standard MIME type.
The url must be an http url.
<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3" length="12216320" type="audio/mpeg" />
A use-case narrative for this element is here.
The use-case narrative, Payloads for RSS, describes how the enclosure was intended for use. In short, the RSS aggregator would suck down the media files in an RSS feed overnight. There's a short description of the new element, which is included in the next block quote.
So that's the philosophy, now let's put some meat on the bones.
RSS already does most of what we want. With the addition of the <enclosure> sub-element of <item> any RSS element can describe a video or audio file (actually any type of file).
<enclosure> has three attributes: url says where the file is located, length says how big it is, and type says what its type is. This way a workstation or aggregator can know in advance, without having to do any communication, what it's going to get, and apply scheduling and filtering rules.
With all this on the table, what does this say about the cardinality of the <enclosure> element in <item>? It says that it's OPTIONAL. If a lawyer read this, then he'd likely say that the element can be present or not. If an Enlish professor read this, then he'd likely say that the element can be present or not. Both the lawyer and professor would likely argue that it says nothing about whether two enclosure elements may be contained within the item parent element.
Now, if someone family with XML schemas read this, then he'd likely say that the enclosure element can have zero or one instance in the parent item element. Why would he exclude multiple instances? Because in XML schemas, the word OPTIONAL has come to mean zero or one, not zero or one or more. Let's take a look at several examples of this.
We'll pretend Google is the official reference to the galaxy (which it is) and query the web for xml dtd optional element. The first article is by Ronald Bourret and it's called Declaring Elements and Attributes in an XML DTD. In one section, he talks about the cardinality of elements and specifically says "Optional (?), one-or-more (+), and zero-or-more (*) operators can be applied to groups, subgroups, and subelements". Note the question mark operator in DTD means zero-or-one and he makes the same assumption that optional implies zero-or-one. Next we get L. Dodds The 10 Minute Guide to Reading an XML DTD. He also uses the word optional to denote the zero-or-one operator in DTDs, although he does note at most one to remove any confusion. The third article is a forum post titled PCDATA followed by an optional element. The author here again uses the word optional to mean zero-or-one.
Now, RSS wasn't written by professors or lawyers, it was written by a computer scientist and it's an implementation of XML. OPTIONAL means zero-or-one in this context. I'm sure some will continue to disagree, but then I have to bring up a further point. If you read OPTIONAL as zero-or-more in the RSS spec, then how many optional <title>s, <link>s and <description>s can an RSS item have? Too many.
The only way to read the spec is that there is at most one instance of enclosure in item. In part II, I'll describe how to implement multiple enclosures now that sane people agree you can only have at most one enclosure in any RSS item.