Tinderbox v10 Icon

OmniOutliner

Tinderbox supports drag-drop importing of OPML exported from OmniOutliner. Sadly, Omni neglect to document their export format in any detail. A scant description can be found here.

Column-to-Attribute mapping

The first column of an OmniOutliner file (default column title 'Topic') will export as OPML attribute 'text' (regardless of the columns title). An OPML 'outline' tag (i.e. row/note) 'text' attribute always maps on import to the Tinderbox $Name attribute of a note (i.e. its title).

If the OmniOutliner column #1 content contains more than one paragraph, the only first paragraph only is exported as as the 'text' attribute, with the rest of the text exporting as the OPML '_note' attribute. Tinderbox always maps '_note' to a note's $Text attribute. For more deliberate export it is possible to put only the row/note title in column #1 and make a column #2 with the column name '_note' and place the intended Tinderbox note text in that column.

All other columns are exported with a custom OPML attribute that matches the column header name. Thus if targeting import to Tinderbox, these columns should use the case-sensitive name of the intended mapped Tinderbox attribute. Thus if aiming to map a column to $SomeAttribute, the OmniOutliner column name should be 'SomeAttribute', and so on.

In summary Tinderbox always maps OPML 'text' to $Name' and '_note' to $Text while any other attribute names (as derived from OmniOutliner column headers) are case-sensitively mapped to an existing Tinderbox attribute or a new user attribute of that name is created.

Regardless of the OmniOutliner source file's column data type, Tinderbox OPML import will always create new Tinderbox attributes as a String type. Thus it is advisable, where possible to define any desired mapped attribute in the TBX file before import, setting the desired.

Pasting an outline from OmniOutliner understands notes associated with OmniOutliner items and saves them in the new note's text.

Data Types

OmniOutliner and Tinderbox data types do not match exactly. The default column type is 'rich text' which is exported to OPML without any styling. The 'number' type in OmniOutliner allows for various formats but is best exported unformatted whether targeting a Tinderbox String or Number type attribute.

Use of the 'checkbox' column type is not recommended as whilst it renders in OmniOutliner like a Tinderbox Boolean attribute the values are exported as 'checked' and 'unchecked' both of which parse into a value of true (ticked) if mapped to a Tinderbox Boolean. Thus it is better to use a 'rich text' type column and 'true' and 'false' values as these will pass correctly into a Tinderbox Boolean attribute.

The 'date' column type displays/exports the short date form 'dd/mm/yyyy' or 'mm/dd/yyyy' the day/month order depending on your OS' locale. Further the delimiter may be other than a '/' depending on your OS' locale. Mapped to a Tinderbox Date attribute this will work fine as long as both OmniOutliner and Tinderbox are running on the same OS locale. If the source OmniOutliner OPML and the Tinderbox app are on different locales (e.g. US vs. non-US) you may need to format the OmniOutliner date column to use the day/month order and delimiter of the recipient OS with the Tinderbox. Note OmniOutliner 'date' columns allow some locale based formatting: see the OmniOutliner manual.

Other OmniOutliner column types are not recommended if creating data intended for export to Tinderbox via OPML.

For multi-value, i.e. list, data values, use a 'rich text' OmniOutliner column and format the text so each value is delimited with a semi-colon, i.e. 'value 1, value 2' should be saved before export as 'value 1;value 2'. On import to a Set or List type Tinderbox attribute this will separate into discrete list values. If imported to a String attribute with is then changed to a Set or List, again it will parse into discrete values.

With appropriate data values, number/boolean/date/list type data imported to Tinderbox as a new string-type attribute should translate correctly if the new attribute is then changed into the correct Tinderbox data type via the Inspector.


See also—notes linking to here: