[epaulson]

It's not so much that OPML is the interesting part here, it's that it's a file. A few weeks back Andrej Karpathy had a twitter thread[1] about blogging software and shared this link on 'File vs App' - https://stephango.com/file-over-app - and that really was great for ecosystem interoperability. I can download the file using whatever tool is appropriate, store it however I want, and then upload it somewhere else using whatever tools is appropriate. I have the OPML export I took of my subscriptions from the day Google Reader shut down and there's still a fighting chance that other services could actually import that file.

It's also worth noting that OPML is only the container format here. Agreeing on a container format is obviously important and we won't get very far for interop if we can't even agree on the container format, but OPML is supposed to be a generic tree of 'outline' format, and conveniently RSS subscriptions (and folders) look like a tree.

I sorta expected that there would be a second standard that says "here's how you use this generic OPML container format to represent RSS feed subscriptions" but oddly that's actually included right in the OPML spec[2]. In fact RSS subscriptions are the only application format defined in OPML - there's a 'type' field defined for <outline> element and if type is set to 'rss' then there's also a required xmlUrl of the feed and optional things like the html link for the blog, the version of RSS used. This is the data and part of the spec that makes the actual subscription list exchange work.

But again the only entry for 'type' defined in the OPML spec is 'rss'. If you want to use OPML as a container for something else, like Youtube subscriptions or Twitter followers, you of course can but you gotta find some way to get everyone to agree on how to interpret the 'type' you set for that <outline> element. And as far as I know, no one's done anything like that for any other domain.

So it'd be awesome if more domains defined 'type' fields and set out some specs so I can export my video streaming subscriptions or Amazon wishlist or whatever but without defining more 'type' fields OPML is really not any more interesting than a CSV of URLs.

[1] https://twitter.com/karpathy/status/1751379269769695601 [2] http://opml.org/spec2.opml

[rcade]

If someone wanted to extend OPML into another domain, even if they got others to agree on their proposed type value and the new attributes added to support that type, there's nothing to stop a collision with somebody else choosing the same attribute names.

There also is nothing to stop the author of the OPML specification from opposing the new type.

It would be far easier to create a new XML format.