OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: OPML and DITA Maps

This is a comment tossed out purely for the long look ahead.

I've been getting some good use out of the OPML 2.0 spec [1] for creating map-editing tools. There are many outline editors (Checkvist [2] is the one I happen to like, but Simplenote and Flicknote on Android are related) that are easy to use on any browser and can export to the OPML format that is easily transformed back into a map for DITA storage. And there are some available _javascript_ tools for building your own map editor based on OPML. All in all, OPML is an incredibly accessible format with available tools that map readily to "nestedSortable" behaviors in browsers--drag and drop [3] or shortcut-driven editing [4] that can hook into other online services and mind map tools that also consume OPML (yep, use MindMap or Freemind to author future DITA maps in a direct format, if we get on this bandwagon).

The OPML 2.0 spec defines only the elements that contribute to the tree relationship; they leave open any specification of the "payload" part of a node since different applications will have different requirements. Also notable, the spec defines a head and body for separating list metadata from the list itself, something that I also find is nicely parallel to topic structure.

Notably, OPML also represents markup for stateful information about the active location in a list. I think the intent was to ensure that the presentation of a list could be picked up again in the same state later on or at a different location. This part is clutter to that spec--it is antithetical to the RESTful way of thinking, so don't let that part distract you. The useful essence is:

  1. Separation of outline structure from application-specific data (wider range of use, at some concern for regulating interchange within a class of use)
  2. Consideration of a head/body structure to better serve separation of metadata from the data model itself.
  3. Intersection with existing Web ways of handling lists of resources. If we can lower this barrier, we greatly extend the uptake of DITA as a first-class Web resource (think of sidebar widgets that can be dynamically created for related lists, categories, etc.).

So this note is for adding to the list of considerations for DITA 2.0-era architecture.

[1] http://dev.opml.org/spec2.html
[2] https://checkvist.com/ (I use the free version to develop my presentation outlines, then transform to DITA map to generate stubs for slides--works great)
[3] https://github.com/ilikenwf/nestedSortable, https://github.com/dbushell/Nestable
[4] http://www.netcrucible.com/xslt/opml.htm

Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday   Twitter: @donrday
About.me: Don R. Day   Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot

Virus-free. www.avast.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]