OPML 被低估了
OPML 是一种基于 XML 的格式，最初为大纲工具创建，后来被用于共享 RSS 订阅列表。它作为一种简单、基于文件的方式，用于在不同服务之间交换精选订阅源和 blogroll，正重新引发兴趣。评论者在权衡它的优点——可读性强的结构、良好的工具支持，以及用于有意识、由人驱动的推荐——与其设计怪癖、缺乏正式标准，以及对自定义元数据和实时“OPML feeds”等更丰富用例支持有限之间的关系。讨论进一步扩展到对 XML/XSLT 和开放的基于 RSS 的生态系统（包括播客）的辩护，把它们视为当今应用中心、围墙花园式 Web 的替代方案；许多人认为，如果把这些较早的开放格式改进好，互联网可能会更健康，没那么“变烂”。
OPML 的互操作性和用例
- 有些人还记得早期 OPML 导出/导入的不兼容；也有人表示，由于格式很简单（就是一个大纲项树），它在多个应用之间“就是能用”。
- OPML 被认为很适合相对静态、树状结构的集合（例如 blogroll、订阅列表），而 RSS/Atom 更适合按时间排序的条目。
- 一些工具支持“实时” OPML 订阅（OPML feeds），这样中央列表的变更就能自动更新阅读器；但许多阅读器仍然只把 OPML 当作一次性的导入/导出格式。
XML、XSLT 和浏览器支持
- 几位评论者怀念 XML/XSLT，认为如果把它们改进好，可能会比现在的 JSON + 重客户端 JS 技术栈带来一个更健康的 Web。
- 也有人指出，浏览器对 XSLT 的支持（停留在 XSLT 1.0）一直被忽视且很脆弱，并存在平台和配置文件特定的 bug。
- 有些人强调 XSLT 很强的用例（声明式模板、流式处理、包含其他 XML 文档），并将其与现代 JS 框架作出积极比较；另一些人则认为，如今 Python/JSON 工具链更实用。
OPML 设计批评
- 批评者说 OPML 是设计很差的 XML：把很长的 HTML 块存进属性里，通过任意属性和“type”值临时扩展，而且没有强大、稳定的标准。
- 该规范只定义了一个正式应用（用于订阅列表的“rss”类型）。将 OPML 用于其他领域（例如 YouTube、Twitter、愿望清单）将需要新的共享约定，而这些目前还不存在。
- 有些人认为，许多 OPML 用例本可以有各自独立、更干净的 XML 格式。
大纲工具和互操作性
- 讨论了 OPML 起源于大纲工具（outliners）。现代大纲工具常为每个节点增加自定义属性（类似数据库的元数据），这些在 OPML 导入/导出时不会被保留，从而限制了互操作性。
- 有人对高级功能（例如图片、自定义字段）实际上形成了供应商锁定感到不满，因为这些内容没有映射到 OPML。
RSS、发现和经济因素
- 一些人把 RSS 看作大规模采用上的“失败”，并认为钱是关键原因：订阅源让把用户困在广告繁重的网站或应用里变得更难。
- 对播客而言，评论者坚持真正的播客必须提供 RSS（或 Atom）源，但找到这些源越来越被 UI、“围墙花园”所遮蔽，或者需要技术性变通。
- 也有人反驳说，几乎所有主流播客仍然都有源，可以通过目录或工具发现，只是对普通听众来说并不明显。