Something theoretical/academic crossed my mind this evening - what the (dis)advantage(s) would be as a content provider for mixing one's podcasted multimedia content in the same RSS feed. Specifically, how wise would it be to have one's multimedia and textual content integrated into a single XML-based pull channel?
I've seen many hybrid feeds that contain text-only articles, as well as <ENCLOSURE> tags containing URIs to MP3s for audio content. But then again, I've also noted several well-known, well-established content providers make the effort to distinctly segregate their feeds by MIME types, keeping audio and text available, but completely separate.
In my own case, I've been supporting for the past six months an XML feed that's served up textual version of my station's news stories, and I'll soon be adding MP3 audio of various content we generate. In that light, you could consider this a "migration" project of sorts. It certainly wouldn't be too painful developmentally to add-in to our current RSS feed the audio content I'm going to introduce, being just another DataTable in to iterate through in a DataSet. It would be nice and clean, and perform beautifully.
What I'm wondering is how practical it would be not only for aggregators already subscribing to my stuff, but also to smaller apps like personal web pages, and then also for the podcast applications that will subscribe to my stuff in the future. At this point, I'm admittedly unjustifiably assuming that the majority of podcast apps, being audio channels in their nature, will ignore <ITEM> nodes in an RSS feed without <ENCLOSURE>. I'm also going to assume that any encountered audio will get an icon or download link of some sort in the major aggregators.
Alas, I think my previous conclusion that "it depends" would be the best advice, considering the context, scale, scope and target audience of an application, so time to start playing.