Forum Posts Feed
Preferred data/attributes in OPML files
< Next Topic | Back to topic list | Previous Topic >
Posted by Robin
Apr 16, 2024 at 12:24 PM
Hi everyone,
while I have long supported OPML export/import in OutlineEdit and enjoy it in many apps, I have some times been uncertain about which data fields should be included and how to name those attributes for the widest compatibility. I would be interested in learning the following from passionate OPML users:
- Which software is your main client for generating/opening OPML files and does it include any special data fields? And which of them do you need?
- What do you think about the approach of adding non-standard fields with a leading underscore (e.g. _note)?
- Is there friction that you encounter in practice when using (partially) incompatible OPML files with some apps?
Really interested in that, looking forward to your experiences with this topic.
Robin
Posted by Paul Korm
Apr 16, 2024 at 02:39 PM
Robin, OPML is the most non-standard standard around. For interoperability, which I looks like you’re going for, I suggest starting with sticking close to Dave Winer’s original spec:
I’ve seen OPML using non-standard tags beginning with the underscore, as you said, but I’ve also had issues with importing that in some cases. At one point Tinderbox chocked in underscore prefixes but that was many versions ago so it’s worth testing again to see if the issue remains.
As far as friction, it might be impossible to stamp out completely—given the many different ways developers speak OPML—but maybe if you could let OutlineEdit users edit (or copy and edit a copy) the output template then users could have a method to work around incompatibility without you chasing that kind of problem.
Posted by satis
Apr 16, 2024 at 05:52 PM
Would extending support to special data fields cause interop problems?
Having used a number of apps which output to OPML (OutlineEdit, Zavala, TaskPaper, Scrivener, CarbonFin [iOS], Cloud Outliner, OmniOutliner, Pocket Casts, Mellel, MindNode, iThoughts X), I don’t know which if any extend OPML to any extent, but I haven’t experienced incompatabilities so I wonder if apps are going beyond standard text fields.
OPML has always been a bit of a confusing mess as a standard. I recall this 2005 blog post, “What’s Wrong With OPML”
https://fishbowl.pastiche.org/2005/10/02/whats_wrong_with_opml
Posted by Dormouse
Apr 16, 2024 at 10:28 PM
satis wrote:
>OPML has always been a bit of a confusing mess as a standard. I recall
>this 2005 blog post, “What’s Wrong With OPML”
And the fact that OPML usually works as an import-export format for outliners and mindmappers just demonstrates the power of undocumented conventions over specifications.
So long as you know, or discover, those conventions that is.
I don’t see many programs using XML for import-export.
I don’t think you’d want to stick too much into it though, because other programs will have no way of understanding unusual extras, and in my experience will usually just ignore them.
Posted by Robin
Apr 17, 2024 at 07:42 AM
Thanks for your input, my current feeling on this topic is, ideally we should move beyond OPML to another open format, but OPML 2.0 is probably here to stay in the long term so there needs to be a backwards-compatible solution in any case.
In my view, it should work best to insert attributes that are used by well known apps or introduce underscored “private” attributes, but add an option to disable their inclusion. On the import side, things get more interesting: Apps could offer an option to “map” unknown attributes to any known one, with an interface similar to how Numbers does CVS imports, allowing for a little bit more flexibility.