Attention:: This effort is on hold until further notice (perhaps after release of version 1.2/1.3).

Introduction

Freeplane version 1.0.x (and 1.1.x) was developed using FreeMind's format and file extension (.mm) in an effort to allow a smooth transition to users willing to switch to Freeplane. As Freeplane grows mature and wants to make true its Visions, a new file format is required.

File types and extensions.

A Freeplane file can come in 4 flavors, as single XML document file or as package:

Single XML document:
1. a plain XML format with extension .freeplane.
  This format allows further for easy automated generation and XSLT transformation.
2. the above format in a standard ZIP or JAR file, i.e. if a file named myfile.freeplane.zip or myfile.freeplane.jar contains a file named myfile.freeplane, it will be opened by Freeplane in the same way as the above plain XML format (other files in the same archive will be ignored).
  The file format is still easy to generate but takes less space than plain XML, is cleaner to email (some mailers choke on text formats) and can be used to transport other files (even though they will be ignored by Freeplane).
Package Document:
1. a more complex zipped format with extension .freeplanez.
  This format allows for embedded styles, images and other 3rd party objects.
2. the same structure but in an uncompressed directory with extension .freeplane.d.

Overall, the XML format is the same in all flavors, and aligned (as much as possible) with the Open Document Format from the OASIS organization.

File format requirements

clean XML
multiple maps per file possible
easy generation
embedding of 3rd party objects
support real styles
allow for comparison between different files
allow for tracked changes

Generic rules

Each XML file must start with an XML declaration <?xml version="1.0" encoding="UTF-8" ?>.
- this means that the Freeplane format is based on XML 1.0 and has UTF-8 as encoding.
- (X)HTML entities are not used anymore for accentuated characters but just plain UTF-8 encoding.
A single XML document may continue with an XSLT reference like <?xml-stylesheet type="application/xslt+xml" href="url-to-some-XHTML-transformation-sheet"?> as to allow web browsers to render directly Freeplane files.
- Freeplane must ignore (but keep) such entries and should add a default one when creating a new map.
- The Freeplane team should offer standard XSLT transformation sheets e.g. under http://freeplane.org/formats/2010/to-xhtml10.xsl.
All XML markups are in small caps and must have an explicit namespace
The namespace must be declared either as xmlns:attribute of the root element of the XML file, or, if rendered by a plug-in, as xmlns:attribute of the XML element rendered by this plug-in
Example

if a node has the xmlns attribute <map:node xmlns:myplug="myplug-namespace" ...>[...], Freeplane could find an OSGi service NodeRenderer with a filter based on the given namespace to render this specific node.
The namespace for Freeplane specific elements is xmlns:map="http://freeplane.org/formats/2010/map".
Until further notice, all formatting elements are based on XHTML 1.0/1.1 and have the namespace xmlns:xhtml="http://www.w3.org/1999/xhtml".
- SimplyHTML must be adapted accordingly, and perhaps released as OSGi bundle!?

Format Specifics

(structure aligned with version 1.2 of the Open Document Format)

Part 1 - XML File Format

1 - Introduction

1.1 to 1.4 - no changes

1.5 - Namespaces

We stick to the same namespaces wherever applicable, and add the following one:

Table 6 - Freeplane namespaces
Prefix	Description	Namespace
map	For all Freeplane specific elements	http://freeplane.org/formats/2010/map
x-office	For Freeplane elements that would belong in the 'office' namespace	http://freeplane.org/formats/2010/office

2 - Scope (not relevant)

3 - Document Structure

3.1 Document Representation

3.1.2 <office:document>(Single OpenDocument XML Files)

A typical single opendocument might look as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="application/xslt+xml" href="http://freeplane.org/formats/2010/to-xhtml10.xsl" ?>
<office:document office:mimetype="application/x-freeplane" office:version="1.2-fp-1.0" xmlns:[...]>
  <office:automatic-styles> [...] </office:automatic-styles>
  <office:body>             [...] </office:body>
  <office:font-face-decls>  [...] </office:font-face-decls>
  <office:master-styles>    [...] </office:master-styles>
  <office:meta>             [...] </office:meta>
  <office:scripts>          [...] </office:scripts>
  <office:settings>         [...] </office:settings>
  <office:styles>           [...] </office:styles>
</office:document>

Notes: Once Freeplane has a registered mime-type, mimetype could become application/freeplane. The version is made of the ODF version 1.2, 'fp' for Freeplane and an internal version number, 1.0 to start with.

3.1.3 Package OpenDocument Files

File content.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<office:document-content office:version="1.2-fp-1.0" xmlns:[...]>
  <office:automatic-styles> [...] </office:automatic-styles>
  <office:body>             [...] </office:body>
  <office:font-face-decls>  [...] </office:font-face-decls>
  <office:scripts>          [...] </office:scripts>
</office:document>

File styles.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<office:document-styles office:version="1.2-fp-1.0" xmlns:[...]>
  <office:automatic-styles> [...] </office:automatic-styles>
  <office:font-face-decls>  [...] </office:font-face-decls>
  <office:master-styles>    [...] </office:master-styles>
  <office:styles>           [...] </office:styles>
</office:document>

File meta.xml:

<?xml version="1.0" office:version="1.2-fp-1.0" encoding="UTF-8" ?>
<office:document-meta xmlns:[...]>
  <office:meta>             [...] </office:meta>
</office:document>

File settings.xml:

<?xml version="1.0" office:version="1.2-fp-1.0" encoding="UTF-8" ?>
<office:document-settings xmlns:[...]>
  <office:settings>         [...] </office:settings>
</office:document>

3.2 <office:meta>

Section can and should be used as-is. No changes needed.

⇒ Freeplane should offer a dialog to enter document information.

3.3 <office:body>

Mandatory section, but only child needed is a Freeplane specific <x-office:map>.

Note: x-office is used instead of office to avoid polluting the 'office' namespace. x-office can be used as an alternative prefix for the same Freeplane namespace as 'map'.

3.4 to 3.9 not needed, replaced by <x-office:map>

<x-office:map> can contain one or more <map:map> element, each representing what is currently the root element of a .mm map (with of course necessary adaptations, e.g. <map:node> instead of <node>).

TBD: The exact content of a map will be described in Freeplane_File_Format/Maps

3.10 <office:settings>

Section can and should be used as-is. No changes needed.

Possibly Freeplane doesn't need the full scope and could cope only with config-item-set and config-item as in:

<office:settings>
  <config:config-item-set config:name="somename">
    <config:config-item config:name="itemname" config:type="itemtype">
      ConfigValue
    </config:config-item>
    [...]
  </config:config-item-set>
  <config:config-item-set config:name="someothername">
    [...]
</office:settings>

Note: as described in chapter 19.32, The values of the config:type attribute are boolean, short, int, long, double, string, datetime or base64Binary.

3.11 Cursor Position Setting

A bit unclear, but I understand something like the following is possible:

<?opendocument cursor-position="XXX" ?>

where XXX is a mean to give the cursor position at the time where the document was saved. In Freeplane's case, it could just be a map and/or node ID, but I'm not fully convinced.

3.12 + 3.13 <office:script[s]>

TBD: The exact handling of scripts will be described in Freeplane_File_Format/Scripts

<office:scripts>
  <office:event-listeners>
    TBD: do we need event listeners in Freeplane? How to implement them?
  </office:event-listeners>
  <office:script script:language="groovy">
    Script Specific Text (can also be a link to an external script)
  </office:script>
  <office:script script:language="lang2">
    [...]
</office:scripts>

3.14 <office:font-face-decls>

<office:font-face-decls>
  <style:font-face [...]>
  </style:font-face>
  <style:font-face>
    [...]
</office:font-face-decls>

I would recommend to skip this function for the next release of Freeplane, chapter 16.21 <style:font-face> seems quite complex to implement. TBD!

3.15 Styles

The elements <office:automatic-styles>, <office:master-styles> and <office:styles> could possibly be used but would possibly need to contain map specific styles.

TBD: The exact handling of styles will be described in Freeplane_File_Format/Styles

3.16 Document and Macro Signatures

The section defines 2 (optional) files described in more details in chapter 2.4 of part 3 of the specification:

META-INF/documentsignatures.xml for signature of all files
META-INF/macrosignatures.xml only for signatures of macros

Does not need to be part of next Freeplane release.

4 Metadata

The specs define 2 types of metadata:

RDF Metadata, to be defined in the file manifest.rdf (more details in part 3)
Non-RDF Metadata, found within the element <office:meta>.

Both can be used as defined in the chapter.

5 to 20 (Content, Formatting, attributes, etc...)

TBD: To Be Used as needed, document here what you use as you implement it!!!

21 Document Processing

Nothing really special...

22 Conformance

Chapter 22.2.2 "Conforming OpenDocument Extended Documents" is interesting as it defines what the new Freeplane format needs to fulfill.

Freeplane itself would need to comply to 22.3.2 "Conforming OpenDocument Extended Producers" and 22.4 "Consumer Conformance".

Appendices A to G

Nothing really relevant in there.

Part 2 - OpenFormula

not applicable (yet?)

Part 3 - Packages

1 Introduction

Nothing really relevant

2 Packages

2.0 list of files

The specification doesn't explicitly contain a list of possible files, so here it is, with a reference to the relevant chapters.

The following table shows a summary of all files to be found in an OpenDocument conform package file, as described in the specification:

Files found in a package according to ODF reference
File name	description	relevant chapter(s)
`mimetype`	first file in ZIP file, uncompressed, contains mime type i.e. application/x-freeplane or application/freeplane	2.3 MIME Media Type
`META-INF/manifest.xml`	manifest file in XML format listing all files in the package with their MIME type and, if needed, encryption options	3 Manifest File
`manifest.rdf`	meta data file (probably optional for Freeplane)	5 Metadata Manifest Files
`META-INF/documentsignatures.xml` `META-INF/macrosignatures.xml`	Signature files respectively for all files and for macros (optional)	4 Digital Signatures File (and in Part 1 - 3.16 Document and Macro Signatures)
`Thumbnails/thumbnail.png`	Preview image of size 256x256 and 24 bits (optional)	2.8 Preview Image
`content.xml` `styles.xml` `meta.xml` `settings.xml`	Core content, styles, metadata and settings files	Part 1

The ODF specification states that a package can contain other files, but it doesn't specify any specific structure (it is also not needed because all such files are referenced in META-INF/manifest.xml). Reading between the lines and analyzing OpenOffice files, I come to the conclusion that all additional files should be in sub-directories with names starting with a capital. Here a few examples/suggestions:

Directories found in a package to contain 3rd party objects
Directory name	description
`Pictures/`	for all images. Freeplane accepts JPEG, PNG and GIF formats.
`Icons/`	for user specific icons. Freeplane accepts JPEG, PNG and GIF formats.
`Scripts/`	for Groovy scripts.
`Objects/`	for any object that Freeplane would embed without actually being able to do anything with it but just try to display externally.

Note: further directories can be added as needed.

Note: to embed objects, OpenOffice creates a binary (format ?) reference file ObjectReplacements/Object N (N a growing index) and puts the relevant data in a sub-directory Object N, but I don't think we want to do this.

2.4 Encryption

probably not in this version of Freeplane

2.7 Usage of IRIs Within Packages

the chapter is a bit unclear, but I understand basically that links to files within the package are just normal relative links. As all files present in the package need to be referenced in META-INF/manifest.xml, Freeplane can safely compare any relative link to the content of this file, and, only if not found, try to resolve the link outside of the package.

Note: when using a packaged directory, the relative link outside of the package means relative to the directory containing the packaged directory. Example: a packaged directory /home/ewl/Documents/mymap.freeplane.d where content.xml refers to Scripts/myscript.groovy; if internal to the package, the absolute path is /home/ewl/Documents/mymap.freeplane.d/Scripts/myscript.groovy, but externally resolved, it means /home/ewl/Documents/Scripts/myscript.groovy.

3 to 5 Manifest, Signatures and Metadata

Relevant without changes, chapters referenced in files table from chapter 2.

6 Datatypes

Not really of interest.

7 Conformance

Relevant summary, to be fulfilled by Freeplane and its format.

New Freeplane File Format (Proposal)

Contents