OPML está infravalorado

Artículo original ↗ Discusión en Hacker News ↗

OPML, un formato basado en XML creado originalmente para outliners y luego adoptado para compartir listas de suscripción RSS, está despertando nuevo interés como una forma simple, basada en archivos, de intercambiar feeds seleccionados y blogrolls entre servicios. Los comentaristas sopesan sus fortalezas —estructura legible por humanos, buen tooling y uso en una recomendación consciente y guiada por personas— frente a sus rarezas de diseño, la falta de un estándar formal y el soporte limitado para casos de uso más ricos como metadatos personalizados y “feeds OPML” en vivo. El hilo se amplía hacia una defensa de XML/XSLT y de ecosistemas abiertos basados en RSS (incluidos los podcasts) como alternativa a la web actual centrada en apps y jardines amurallados, y muchos sostienen que mejorar estos formatos abiertos más antiguos podría haber llevado a Internet a ser más saludable y menos “enshittified”.

Interoperabilidad y casos de uso de OPML

  • Algunos recuerdan incompatibilidades tempranas de exportación/importación de OPML; otros informan que “simplemente funciona” en múltiples apps porque el formato es simple (un árbol de elementos de esquema).
  • Se considera que OPML encaja bien para colecciones relativamente estáticas y estructuradas en árbol (p. ej., blogrolls, listas de feeds), mientras que RSS/Atom son mejores para elementos ordenados en el tiempo.
  • Unas pocas herramientas admiten suscripciones OPML “en vivo” (feeds OPML), de modo que los cambios en una lista central se actualizan automáticamente en un lector; muchos lectores siguen tratando OPML solo como importación/exportación puntual.

XML, XSLT y compatibilidad con navegadores

  • Varios comentaristas expresan nostalgia por XML/XSLT, argumentando que mejorarlos podría haber llevado a una web más saludable que la pila actual de JSON + JS pesado en el cliente.
  • Otros señalan que el soporte de XSLT en los navegadores (atascado en XSLT 1.0) está descuidado y es frágil, con errores específicos de plataforma y perfil.
  • Algunos destacan casos de uso potentes de XSLT (plantillas declarativas, streaming, inclusión de otros documentos XML) y lo comparan favorablemente con los frameworks modernos de JS, mientras que otros encuentran hoy más práctico el tooling de Python/JSON.

Críticas al diseño de OPML

  • Los críticos dicen que OPML está mal diseñado como XML: bloques HTML largos almacenados en atributos, extensión ad hoc mediante atributos arbitrarios y valores “type”, y ausencia de un estándar fuerte y estable.
  • La especificación define solo una aplicación formal (“rss” type para listas de suscripción). Usar OPML para otros dominios (p. ej., YouTube, Twitter, listas de deseos) requeriría nuevas convenciones compartidas que aún no existen.
  • Algunos sostienen que muchos casos de uso de OPML podrían haber sido formatos XML separados y más limpios en su lugar.

Outliners e interoperabilidad

  • Se discute el origen de OPML en los outliners. Los outliners modernos suelen añadir propiedades personalizadas por nodo (metadatos tipo BD) que no se conservan en la importación/exportación de OPML, lo que limita la interoperabilidad.
  • Hay frustración porque las funciones avanzadas (p. ej., imágenes, campos personalizados) se convierten en un bloqueo de proveedor en la práctica, ya que no se mapearon a OPML.

RSS, descubrimiento y economía

  • Algunos ven RSS como un “fracaso” en su adopción masiva, citando el dinero como razón clave: los feeds dificultan atrapar a los usuarios en sitios o apps llenos de anuncios.
  • Para los podcasts, los comentaristas insisten en que un podcast de verdad debe exponer un feed RSS (o Atom), pero encontrar esos feeds queda cada vez más oculto tras la interfaz, los “walled gardens”, o requiere soluciones técnicas.
  • Otros responden que prácticamente todos los podcasts convencionales sí siguen teniendo feeds, descubribles mediante directorios o herramientas, aunque no sea obvio para la audiencia promedio.