[Via [Scott's "SiteExperts" Place](http://spaces.msn.com/members/siteexperts/Blog/cns!1pNcL8JwTfkkjv4gg6LkVCpw!2577.entry)][[posterous-content:atpdzDnmGuhzkvkrfEsu]][[posterous-content:imJeHHGFGEfBuxpHwsrd]]
I am not an Opml expert. This is the results of my observations of a couple Opml feeds. I fail to see how to adequately leverage Opml in the mash-up web world.
A few weeks ago, I published a demonstration for searching multiple site's entirely via the web-browser. I was illustrating the value of opening up unauthenticaed cross-domain xmlhttp requests and the opportunities that would create.
I planned to build a new demo that can "mash-up" Opml. This demo would take an XML feed (whether RSS, Atom, or Opml) and render it. For Opml lists, I wanted to expand each list item based on type. Opml files (e.g., reading lists) expansion would have been a powerful expression. Loading an Opml file would render the list. Each outline item would be rendered based on type within the page - links to other Opml lists would expand in outline format, links to Rss feeds would expand with the feed in place, links to Mp3 or videos would expand with a media player, html pages could expand with a preview of the page, and so on. This provides a foundation for a a very quick and effective newspaper page.
Developing this should have been trivial. The base code was less than a few screenfuls. However, my good intentions quickly fell apart because I discovered that Opml provides no (actually minimal) semantics to understand the items in the list without having to physically request them.
Opml apparently has a type attribute. However, this type attribute is not well defined. According to the Opml Guidelines, this merely tells you that the link is an Rss feed or something else. Something else is pretty broad. Having to request the resource to somehow determine its type is a non-starter (I am not downloading a multi-megabyte video just to know its a video). Even worse, different feeds use the url and xmlurl fields differently. I found Opml files that list each type as a "link" and then the url refers to an Rss file. Even in the most recent post dated a week ago, Validating OPML, while the type attribute is considered required, it still appears to distinguish only between Rss and the everything else. I can't understand why isn't type just the mime-type?
I know this has been a challenge for others as I found code attempting to determine types via the file extension on the Url. This approach is very unreliable especially with the dynamic nature of many sites (Many times every file, regardless of actually mime-type, will end in extensions such as .aspx, .php, etc.).
So... I guess I don't get it. A list is interesting but without knowing what is in the list I fail to see how I can adequately leverage and "mash" it up into a greater experience.
Please enlighten me.
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.