Finally, someone like me who has trouble seeing what you can do with opml [see below]. I have been in the same boat, I spent three days finding resources about the type/url, xmlurl etc attributes. I had no idea what to do with them! It is not standard, but it is meant to be that way [for some reason]. I spent three days looking for common ways to define outlines but could find a consistent way that everyone uses. It appears that if you create whatever attribute you want, document it and enough people use it and recognise it, then it will become a "standard" attribute.

I have a couple of posts on http://tagger.kinlan.co.uk about this and the JavaScript OPML object model I am trying to create (http://www.kinlan.co.uk/AjaxExperiments/opml.js) I use it on http://www.kinlan.co.uk/AjaxExperiments/AjaxTag2 [which isn't finished yet so it might take a bit of getting used too], I use it because based on a blog post there can be many many related links/resources/searches that a user might want to look at based on a blog entry. I though it would be handy to have an OPML file to look at instead of all the links cloging up the blog.

As for determining the file type then I am can't really help you because as far as my app is concerned it doesn't care what type it is because all it uses is links for pages and images. I need to add support for feeds.

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.

[[posterous-content:atpdzDnmGuhzkvkrfEsu]][[posterous-content:imJeHHGFGEfBuxpHwsrd]]

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.

I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.

I'm trialing a newsletter, you can subscribe below (thank you!)

Enter your email

Book a consultation