OPML is underrated
OPML, an XML-based format originally created for outliners and later adopted for sharing RSS subscription lists, is seeing renewed interest as a simple, file-based way to exchange curated feeds and blogrolls across services. Commenters weigh its strengths—human-readable structure, good tooling, and use in conscious, person-driven recommendation—against design quirks, lack of a formal standard, and limited support for richer use cases like custom metadata and live “OPML feeds.” The thread broadens into a defense of XML/XSLT and open RSS-based ecosystems (including podcasts) as an alternative to today’s app-centric, walled-garden web, with many arguing that improving these older open formats might have led to a healthier, less “enshittified” internet.
OPML interoperability and use cases
- Some recall early OPML export/import incompatibilities; others report it “just works” across multiple apps because the format is simple (a tree of outline items).
- OPML is seen as a good fit for relatively static, tree-structured collections (e.g., blogrolls, feed lists), whereas RSS/Atom are better for time-ordered items.
- A few tools support “live” OPML subscriptions (OPML feeds) so that changes to a central list auto-update a reader; many readers still treat OPML as one-time import/export only.
XML, XSLT, and browser support
- Several commenters express nostalgia for XML/XSLT, arguing that improving them might have led to a healthier web than the current JSON + heavy client JS stack.
- Others note that browser XSLT support (stuck at XSLT 1.0) is neglected and fragile, with platform- and profile-specific bugs.
- Some highlight powerful XSLT use cases (declarative templating, streaming, including other XML documents) and compare it favorably to modern JS frameworks, while others find Python/JSON tooling more practical today.
OPML design critiques
- Critics say OPML is poorly designed XML: long HTML blocks stored in attributes, ad‑hoc extension via arbitrary attributes and “type” values, and no strong, stable standard.
- The spec defines only one formal application (“rss” type for subscription lists). Using OPML for other domains (e.g., YouTube, Twitter, wishlists) would require new shared conventions that don’t yet exist.
- Some argue many OPML use cases could have been separate, cleaner XML formats instead.
Outliners and interoperability
- OPML’s origin in outliners is discussed. Modern outliners often add custom per-node properties (DB-like metadata) that are not preserved in OPML import/export, limiting interoperability.
- There’s frustration that advanced features (e.g., images, custom fields) are effectively vendor lock‑in because they’re not mapped to OPML.
RSS, discovery, and economics
- RSS is viewed by some as a “failure” in mass adoption, with money cited as a key reason: feeds make it harder to trap users in ad-heavy sites or apps.
- For podcasts, commenters insist that a true podcast must expose an RSS (or Atom) feed, but finding those feeds is increasingly obscured behind UI, “walled gardens,” or requires technical workarounds.
- Others counter that virtually all mainstream podcasts still do have feeds, discoverable via directories or tools, though not obvious to average listeners.