I think one of the problems may be that the meaning of the OPML specification for <expansionState>, and the implication of “order is important” turns on what is known is some circles as a hapax legomenon – the word "flatdown"
See, for example, an expression of slightly unresolved puzzlement at:
Are the expansionState integers:
- Zero-based absolute line numbers ? (This turns out to be the Omni interpretation), or
- One-based ordinals which don’t count lines that remain hidden by folding ? ( This turns out to be what the OPML specification means)
Interpretations seem to diverge … the river parts on the meaning of flatdown …
(And the computation, either way, might be fairly expensive with big documents ?)
To illustrate the lack of useable consistency in how different apps write and interpret OPML <expansionState> integer lists. This outline:
In which:
- Beta and Iota are folded
- but Alpha Gamma and Delta are expanded
is, according to OmniOutliner (fairly influential)
<expansionState>0,5,12</expansionState>
but according to Little Outliner 2, written by the author of the OPML specification (Dave Winer), it is:
<expansionState>1,3,7</expansionState>
perhaps this undermines the usefulness of the approach, in terms of shuttling between apps ?
FWIW
As far as I can see, the Omni interpretation seems to be: zero-based absolute line numbers, (0, 5, 12 = Alpha, Gamma, Delta)
whereas the OPML spec seems to be: a one-based ordinal sequence that skips the counting of any lines that are to remain hidden by folding. (1, 3, 7 = Alpha, Gamma, Delta)