Move documentation to metadata files and convert it to Markdown

2 files changed, 398 insertions, 353 deletions

diff --git a/lv2/state/state.meta.ttl b/lv2/state/state.meta.ttl
index 784946d..ac3f2d6 100644
--- a/lv2/state/state.meta.ttl
+++ b/lv2/state/state.meta.ttl
@@ -1,7 +1,9 @@
 @prefix dcs: <http://ontologi.es/doap-changeset#> .
 @prefix doap: <http://usefulinc.com/ns/doap#> .
 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
+@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix state: <http://lv2plug.in/ns/ext/state#> .
 
 <http://lv2plug.in/ns/ext/state>
 	a doap:Project ;
@@ -73,5 +75,382 @@
 				rdfs:label "Initial release."
 			]
 		]
-	] .
+	] ;
+	lv2:documentation """
+
+This extension defines a simple mechanism that allows hosts to save and restore
+a plugin instance's state.  The goal is for an instance's state to be
+completely described by port values and a simple dictionary.
+
+The <q>state</q> defined here is conceptually a key:value dictionary, with URI keys
+and values of any type. For performance reasons the key and value type are
+actually a "URID", a URI mapped to an integer. A single key:value pair is
+called a "property".
+
+This state model is simple yet has many benefits:
+
+  * Both fast and extensible thanks to URID keys.
+
+  * No limitations on possible value types.
+
+  * Easy to serialise in almost any format.
+
+  * Easy to store in a typical "map" or "dictionary" data structure.
+
+  * Elegantly described in Turtle, so state can be described in LV2 data files
+    (including presets).
+
+  * Does not impose any file formats, data structures, or file system
+    requirements.
+
+  * Suitable for portable persistent state as well as fast in-memory snapshots.
+
+  * Keys _may_ be well-defined and used meaningfully across several
+    implementations.
+
+  * State _may_ be dynamic, but plugins are not required to have a dynamic
+    dictionary data structure available.
+
+To implement state, the plugin provides a state:interface to the host. To save
+or restore, the host calls LV2_State_Interface::save() or
+LV2_State_Interface::restore(), passing a callback to be used for handling a
+single property. The host is free to implement property storage and retrieval
+in any way.
+
+Since value types are defined by URI, any type is possible. However, a set of
+standard types is defined by the [LV2 Atom](atom.html) extension. Use of these
+types is recommended. Hosts MUST implement at least
+[atom:String](atom.html#String), which is simply a C string.
+
+### Referring to Files
+
+Plugins may need to refer to existing files (e.g. loaded samples) in their
+state. This is done by storing the file's path as a property just like any
+other value. However, there are some rules which MUST be followed when storing
+paths, see state:mapPath for details. Plugins MUST use the type
+[atom:Path](atom.html#Path) for all paths in their state.
+
+Plugins are strongly encouraged to avoid creating files, instead storing all
+state as properties. However, occasionally the ability to create files is
+necessary. To make this possible, the host can provide the feature
+state:makePath which allocates paths for plugin-created files. Plugins MUST
+NOT create files in any other locations.
+
+### Plugin Code Example
+
+    :::c
+
+    /* Namespace for this plugin's keys.  This SHOULD be something that could be
+       published as a document, even if that document does not exist right now.
+    */
+    #define NS_MY "http://example.org/myplugin/schema#"
+
+    #define DEFAULT_GREETING "Hello"
+
+    LV2_Handle
+    my_instantiate(...)
+    {
+        MyPlugin* plugin = ...;
+        plugin->uris.atom_String = map_uri(LV2_ATOM__String);
+        plugin->uris.my_greeting = map_uri(NS_MY "greeting");
+        plugin->state.greeting   = strdup(DEFAULT_GREETING);
+        return plugin;
+    }
+
+    LV2_State_Status
+    my_save(LV2_Handle                 instance,
+            LV2_State_Store_Function   store,
+            LV2_State_Handle           handle,
+            uint32_t                   flags,
+            const LV2_Feature *const * features)
+    {
+        MyPlugin*   plugin   = (MyPlugin*)instance;
+        const char* greeting = plugin->state.greeting;
+
+        store(handle,
+              plugin->uris.my_greeting,
+              greeting,
+              strlen(greeting) + 1,  // Careful!  Need space for terminator
+              plugin->uris.atom_String,
+              LV2_STATE_IS_POD | LV2_STATE_IS_PORTABLE);
+
+        return LV2_STATE_SUCCESS;
+    }
+
+    LV2_State_Status
+    my_restore(LV2_Handle                  instance,
+               LV2_State_Retrieve_Function retrieve,
+               LV2_State_Handle            handle,
+               uint32_t                    flags,
+               const LV2_Feature *const *  features)
+    {
+        MyPlugin* plugin = (MyPlugin*)instance;
+
+        size_t      size;
+        uint32_t    type;
+        uint32_t    flags;
+        const char* greeting = retrieve(
+            handle, plugin->uris.my_greeting, &size, &type, &flags);
+
+        if (greeting) {
+            free(plugin->state->greeting);
+            plugin->state->greeting = strdup(greeting);
+        } else {
+            plugin->state->greeting = strdup(DEFAULT_GREETING);
+        }
+
+        return LV2_STATE_SUCCESS;
+    }
+
+    const void*
+    my_extension_data(const char* uri)
+    {
+        static const LV2_State_Interface state_iface = { my_save, my_restore };
+        if (!strcmp(uri, LV2_STATE__interface)) {
+            return &state_iface;
+        }
+    }
+
+### Host Code Example
+
+    :::c
+    LV2_State_Status
+    store_callback(LV2_State_Handle handle,
+                   uint32_t         key,
+                   const void*      value,
+                   size_t           size,
+                   uint32_t         type,
+                   uint32_t         flags)
+    {
+        if ((flags & LV2_STATE_IS_POD)) {
+            // We only care about POD since we're keeping state in memory only.
+            // Disk or network use would also require LV2_STATE_IS_PORTABLE.
+            Map* state_map = (Map*)handle;
+            state_map->insert(key, Value(copy(value), size, type));
+            return LV2_STATE_SUCCESS;;
+        } else {
+            return LV2_STATE_ERR_BAD_FLAGS; // Non-POD events are unsupported
+        }
+    }
+
+    Map
+    get_plugin_state(LV2_Handle instance)
+    {
+        LV2_State* state = instance.extension_data(LV2_STATE__interface);
+
+        // Request a fast/native/POD save, since we're just copying in memory
+        Map state_map;
+        state.save(instance, store_callback, &state_map,
+                   LV2_STATE_IS_POD|LV2_STATE_IS_NATIVE);
+
+        return state_map;
+    }
+
+### Extensions to this Specification
+
+It is likely that other interfaces for working with plugin state will be
+developed as needed. This is encouraged, however everything SHOULD work within
+the state _model_ defined here. That is, **do not complicate the state
+model**. Implementations can assume the following:
+
+  * The current port values and state dictionary completely describe a plugin
+    instance, at least well enough that saving and restoring will yield an
+    "identical" instance from the user's perspective.
+
+  * Hosts are not expected to save and/or restore any other attributes of a
+    plugin instance.
+
+### The "Property Principle"
+
+The main benefit of this meaningful state model is that it can double as a
+plugin control/query mechanism. For plugins that require more advanced control
+than simple control ports, instead of defining a set of commands, define
+properties whose values can be set appropriately. This provides both a way to
+control and save that state "for free", since there is no need to define
+commands _and_ a set of properties for storing their effects. In particular,
+this is a good way for UIs to achieve more advanced control of plugins.
+
+This "property principle" is summed up in the phrase: "Don't stop; set playing
+to false".
+
+This extension does not define a dynamic mechanism for state access and
+manipulation. The [LV2 Patch](patch.html) extension defines a generic set of
+messages which can be used to access or manipulate properties, and the [LV2
+Atom](atom.html) extension defines a port type and data container capable of
+transmitting those messages.
+
+"""^^lv2:Markdown .
+
+state:interface
+	lv2:documentation """
+
+A structure (LV2_State_Interface) which contains functions to be called by the
+host to save and restore state.  In order to support this extension, the plugin
+must return a valid LV2_State_Interface from LV2_Descriptor::extension_data()
+when it is called with URI LV2_STATE__interface.
+
+The plugin data file should describe this like so:
+
+    :::turtle
+    @prefix state: &lt;http://lv2plug.in/ns/ext/state#&gt; .
+
+    &lt;plugin&gt;
+        a lv2:Plugin ;
+        lv2:extensionData state:interface .
+
+"""^^lv2:Markdown .
+
+state:State
+	lv2:documentation """
+
+This type should be used wherever instance state is described.  The properties
+of a resource with this type correspond directly to the properties of the state
+dictionary (except the property that states it has this type).
+
+"""^^lv2:Markdown .
+
+state:loadDefaultState
+	lv2:documentation """
+
+This feature indicates that the plugin has default state listed with the
+state:state property which should be loaded by the host before running the
+plugin.  Requiring this feature allows plugins to implement a single state
+loading mechanism which works for initialisation as well as restoration,
+without having to hard-code default state.
+
+To support this feature, the host MUST restore the default state after
+instantiating the plugin but before calling run().
+
+"""^^lv2:Markdown .
+
+state:state
+	lv2:documentation """
+
+This property may be used anywhere a state needs to be described, for example:
+
+    :::turtle
+    @prefix eg: &lt;http://example.org/&gt; .
+
+    &lt;plugin-instance&gt;
+        state:state [
+            eg:somekey "some value" ;
+            eg:someotherkey "some other value" ;
+            eg:favourite-number 2
+        ] .
+
+"""^^lv2:Markdown .
+
+state:mapPath
+	lv2:documentation """
+
+This feature maps absolute paths to/from <q>abstract paths</q> which are stored
+in state.  To support this feature a host must pass an LV2_Feature with URI
+LV2_STATE__mapPath and data pointed to an LV2_State_Map_Path to the plugin's
+LV2_State_Interface methods.
+
+The plugin MUST map _all_ paths stored in its state (including those inside any
+files).  This is necessary so that hosts can handle file system references
+correctly, for example to share common files, or bundle state for distribution
+or archival.
+
+For example, a plugin may write a path to a state file like so:
+
+    :::c
+    void write_path(LV2_State_Map_Path* map_path, FILE* myfile, const char* path)
+    {
+        char* abstract_path = map_path->abstract_path(map_path->handle, path);
+        fprintf(myfile, "%s", abstract_path);
+        free(abstract_path);
+    }
+
+Then, later reload the path like so:
+
+    :::c
+    char* read_path(LV2_State_Map_Path* map_path, FILE* myfile)
+    {
+        /* Obviously this is not production quality code! */
+        char abstract_path[1024];
+        fscanf(myfile, "%s", abstract_path);
+        return map_path->absolute_path(map_path->handle, abstract_path);
+    }
+
+"""^^lv2:Markdown .
+
+state:makePath
+	lv2:documentation """
+
+This feature allows plugins to create new files and/or directories.  To support
+this feature the host passes an LV2_Feature with URI LV2_STATE__makePath and
+data pointed to an LV2_State_Make_Path to the plugin.  The host may make this
+feature available only during save by passing it to
+LV2_State_Interface::save(), or available any time by passing it to
+LV2_Descriptor::instantiate().  If passed to LV2_State_Interface::save(), the
+feature MUST NOT be used beyond the scope of that call.
+
+The plugin is guaranteed a hierarchical namespace unique to that plugin
+instance, and may expect the returned path to have the requested path as a
+suffix.  There is one such namespace, even if the feature is passed to both
+LV2_Descriptor::instantiate() and LV2_State_Interface::save().  Beyond this,
+the plugin MUST NOT make any assumptions about the returned paths.
+
+Like any other paths, the plugin MUST map these paths using state:mapPath
+before storing them in state.  The plugin MUST NOT assume these paths will be
+available across a save/restore otherwise, that is, only mapped paths saved to
+state are persistent, any other created paths are temporary.
+
+For example, a plugin may create a file in a subdirectory like so:
+
+    :::c
+    char* save_myfile(LV2_State_Make_Path* make_path)
+    {
+        char* path   = make_path->path(make_path->handle, "foo/bar/myfile.txt");
+        FILE* myfile = fopen(path, 'w');
+        fprintf(myfile, "I am some data");
+        fclose(myfile);
+        return path;
+    }
+
+"""^^lv2:Markdown .
+
+state:threadSafeRestore
+	lv2:documentation """
+
+If a plugin supports this feature, its LV2_State_Interface::restore method is
+thread-safe and may be called concurrently with audio class functions.
+
+To support this feature, the host MUST pass a
+[work:schedule](worker.html#schedule) feature to the restore method, which will
+be used to complete the state restoration.  The usual mechanics of the worker
+apply: the host will call the plugin's work method, which emits a response
+which is later applied in the audio thread.
+
+The host is not required to block audio processing while restore() and work()
+load the state, so this feature allows state to be restored without dropouts.
+
+"""^^lv2:Markdown .
+
+state:freePath
+	lv2:documentation """
+
+This feature provides a function that can be used by plugins to free paths that
+were allocated by the host via other state features (state:mapPath and
+state:makePath).
+
+"""^^lv2:Markdown .
+
+state:Changed
+	lv2:documentation """
+
+A notification that the internal state of the plugin has been changed in a way
+that the host can not otherwise know about.
+
+This is a one-way notification, intended to be used as the type of an
+[Object](atom.html#Object) sent from plugins when necessary.
+
+Plugins SHOULD emit such an event whenever a change has occurred that would
+result in a different state being saved, but not when the host explicity makes
+a change which it knows is likely to have that effect, such as changing a
+parameter.
+
+"""^^lv2:Markdown .
 
diff --git a/lv2/state/state.ttl b/lv2/state/state.ttl
index 2140309..de6d18b 100644
--- a/lv2/state/state.ttl
+++ b/lv2/state/state.ttl
@@ -5,388 +5,54 @@
 
 <http://lv2plug.in/ns/ext/state>
 	a lv2:Specification ;
+	rdfs:label "LV2 State" ;
+	rdfs:comment "An interface for LV2 plugins to save and restore state." ;
 	rdfs:seeAlso <state.h> ,
-		<state.meta.ttl> ;
-	lv2:documentation """
-<p>This extension defines a simple mechanism which allows hosts to save and
-restore a plugin instance's state.  The goal is for an instance's state to be
-<em>completely</em> described by port values (as with all LV2 plugins) and a
-simple dictionary.</p>
-
-<p>The <q>state</q> defined here is conceptually a key:value dictionary, with
-URI keys and values of any type.  For performance reasons the key and value
-type are actually a <q>URID</q>, a URI mapped to an integer.  A single
-key:value pair is called a <q>property</q>.</p>
-
-<p>This state model is simple yet has many benefits:</p>
-<ul>
-  <li>Both fast and extensible thanks to URID keys.</li>
-  <li>No limitations on possible value types.</li>
-  <li>Easy to serialise in almost any format.</li>
-  <li>Easy to store in a typical <q>map</q> or <q>dictionary</q> data
-  structure.</li>
-  <li>Elegantly described in Turtle, so state can be described in LV2 data
-  files (including presets).</li>
-  <li>Does not impose any file formats, data structures, or file system
-  requirements.</li>
-  <li>Suitable for portable persistent state as well as fast in-memory
-  snapshots.</li>
-  <li>Keys <em>may</em> be well-defined and used meaningfully across several
-  implementations.</li>
-  <li>State <em>may</em> be dynamic, but plugins are not required to have a
-  dynamic dictionary data structure available.</li>
-</ul>
-
-<p>To implement state, the plugin provides a state:interface to the host.  To
-save or restore, the host calls LV2_State_Interface::save() or
-LV2_State_Interface::restore(), passing a callback to be used for handling a
-single property.  The host is free to implement property storage and retrieval
-in any way.</p>
-
-<p>Since value types are defined by URI, any type is possible.  However, a set
-of standard types is defined by the <a href="atom.html">LV2 Atom</a>
-extension.  Use of these types is recommended.  Hosts MUST implement at least
-<a href="atom.html#String">atom:String</a>, which is simply a C
-string.</p>
-
-<h3>Referring to Files</h3>
-
-<p>Plugins may need to refer to existing files (e.g. loaded samples) in their
-state.  This is done by storing the file's path as a property just like any
-other value.  However, there are some rules which MUST be followed when storing
-paths, see state:mapPath for details.  Plugins MUST use the type <a
-href="atom.html#Path">atom:Path</a> for all paths in their state.</p>
-
-<p>Plugins are strongly encouraged to avoid creating files, instead storing all
-state as properties.  However, occasionally the ability to create files is
-necessary.  To make this possible, the host can provide the feature
-state:makePath which allocates paths for plugin-created files.  Plugins MUST
-NOT create files in any other locations.</p>
-
-<h3>Plugin Code Example</h3>
-
-<pre class="c-code">
-
-/* Namespace for this plugin's keys.  This SHOULD be something that could be
-   published as a document, even if that document does not exist right now.
-*/
-#define NS_MY "http://example.org/myplugin/schema#"
-
-#define DEFAULT_GREETING "Hello"
-
-LV2_Handle
-my_instantiate(...)
-{
-    MyPlugin* plugin = ...;
-    plugin->uris.atom_String = map_uri(LV2_ATOM__String);
-    plugin->uris.my_greeting = map_uri(NS_MY "greeting");
-    plugin->state.greeting   = strdup(DEFAULT_GREETING);
-    return plugin;
-}
-
-LV2_State_Status
-my_save(LV2_Handle                 instance,
-        LV2_State_Store_Function   store,
-        LV2_State_Handle           handle,
-        uint32_t                   flags,
-        const LV2_Feature *const * features)
-{
-    MyPlugin*   plugin   = (MyPlugin*)instance;
-    const char* greeting = plugin->state.greeting;
-
-    store(handle,
-          plugin->uris.my_greeting,
-          greeting,
-          strlen(greeting) + 1,  // Careful!  Need space for terminator
-          plugin->uris.atom_String,
-          LV2_STATE_IS_POD | LV2_STATE_IS_PORTABLE);
-
-    return LV2_STATE_SUCCESS;
-}
-
-LV2_State_Status
-my_restore(LV2_Handle                  instance,
-           LV2_State_Retrieve_Function retrieve,
-           LV2_State_Handle            handle,
-           uint32_t                    flags,
-           const LV2_Feature *const *  features)
-{
-    MyPlugin* plugin = (MyPlugin*)instance;
-
-    size_t      size;
-    uint32_t    type;
-    uint32_t    flags;
-    const char* greeting = retrieve(
-        handle, plugin->uris.my_greeting, &amp;size, &amp;type, &amp;flags);
-
-    if (greeting) {
-        free(plugin->state->greeting);
-        plugin->state->greeting = strdup(greeting);
-    } else {
-        plugin->state->greeting = strdup(DEFAULT_GREETING);
-    }
-
-    return LV2_STATE_SUCCESS;
-}
-
-const void*
-my_extension_data(const char* uri)
-{
-    static const LV2_State_Interface state_iface = { my_save, my_restore };
-    if (!strcmp(uri, LV2_STATE__interface)) {
-        return &amp;state_iface;
-    }
-}
-</pre>
-
-<h3>Host Code Example</h3>
-
-<pre class="c-code">
-LV2_State_Status
-store_callback(LV2_State_Handle handle,
-               uint32_t         key,
-               const void*      value,
-               size_t           size,
-               uint32_t         type,
-               uint32_t         flags)
-{
-    if ((flags &amp; LV2_STATE_IS_POD)) {
-        /* We only care about POD since we're keeping state in memory only.
-           For disk or network use, LV2_STATE_IS_PORTABLE must also be checked.
-        */
-        Map* state_map = (Map*)handle;
-        state_map->insert(key, Value(copy(value), size, type));
-        return 0;
-    } else {
-        return 1; /* Non-POD events are unsupported. */
-    }
-}
-
-Map
-get_plugin_state(LV2_Handle instance)
-{
-    LV2_State* state = instance.extension_data(LV2_STATE__interface);
-    Map state_map;
-    /** Request a fast/native/POD save, since we're just copying in memory */
-    state.save(instance, store_callback, &amp;state_map,
-               LV2_STATE_IS_POD|LV2_STATE_IS_NATIVE);
-    return state_map;
-}
-</pre>
-
-<h3>Extensions to this Specification</h3>
-
-<p>It is likely that other interfaces for working with plugin state will be
-developed as needed.  This is encouraged, however everything SHOULD work within
-the state <em>model</em> defined here.  That is, <strong>do not complicate the
-state model</strong>.  Implementations can assume the following:</p>
-
-<ul>
-<li>The current port values and state dictionary completely describe a plugin
-instance, at least well enough that saving and restoring will yield an
-<q>identical</q> instance from the user's perspective.</li>
-<li>Hosts are not expected to save and/or restore any other attributes of a
-plugin instance.</li>
-</ul>
-
-<h3>The <q>Property Principle</q></h3>
-
-<p>The main benefit of this meaningful state model is that it can double as a
-plugin control/query mechanism.  For plugins that require more advanced control
-than simple control ports, instead of defining a set of commands, define
-properties whose values can be set appropriately.  This provides both a way to
-control and save that state <q>for free</q>, since there is no need to define
-commands <em>and</em> a set of properties for storing their effects.  In
-particular, this is a good way for UIs to achieve more advanced control of
-plugins.</p>
-
-<p>This <q>property principle</q> is summed up in the phrase:
-<q>Don't stop; set playing to false</q>.</p>
-
-<p>This extension does not define a dynamic mechanism for state access and
-manipulation.  The <a href="patch.html">LV2 Patch</a> extension
-defines a generic set of messages which can be used to access or manipulate
-properties, and the <a href="atom.html">LV2 Atom</a> extension defines
-a port type and data container capable of transmitting those messages.</p>
-""" .
+		<state.meta.ttl> .
 
 state:interface
 	a lv2:ExtensionData ;
-	lv2:documentation """
-<p>A structure (LV2_State_Interface) which contains functions to be called by
-the host to save and restore state.  In order to support this extension, the
-plugin must return a valid LV2_State_Interface from
-LV2_Descriptor::extension_data() when it is called with URI
-LV2_STATE__interface.</p>
-
-<p>The plugin data file should describe this like so:</p>
-<pre class="turtle-code">
-@prefix state: &lt;http://lv2plug.in/ns/ext/state#&gt; .
-
-&lt;plugin&gt;
-    a lv2:Plugin ;
-    lv2:extensionData state:interface .
-</pre>
-""" .
+	rdfs:label "interface" ;
+	rdfs:comment "A plugin interface for saving and restoring state." .
 
 state:State
 	a rdfs:Class ;
 	rdfs:label "State" ;
-	lv2:documentation """
-<p>A state dictionary.  This type should be used wherever instance state is
-described.  The properties of a resource with this type correspond directly to
-the properties of the state dictionary (except the property that states it has
-this type).</p>
-""" .
+	rdfs:comment "LV2 plugin state." .
 
 state:loadDefaultState
 	a lv2:Feature ;
-	lv2:documentation """
-<p>This feature indicates that the plugin has default state listed with the
-state:state property which should be loaded by the host before running the
-plugin.  Requiring this feature allows plugins to implement a single state
-loading mechanism which works for initialisation as well as restoration,
-without having to hard-code default state.</p>
-
-<p>To support this feature, the host MUST <q>restore</q> the default state
-after instantiating the plugin but before calling run().</p>
-""" .
+	rdfs:label "load default state" ;
+	rdfs:comment "A feature indicating that the plugin has default state." .
 
 state:state
 	a rdf:Property ;
 	rdfs:label "state" ;
 	rdfs:range state:State ;
-	lv2:documentation """
-<p>The state of this instance.  This property may be used anywhere a state
-needs to be described, for example:</p>
-
-<pre class="turtle-code">
-@prefix eg: &lt;http://example.org/&gt; .
-
-&lt;plugin-instance&gt;
-    state:state [
-        eg:somekey "some value" ;
-        eg:someotherkey "some other value" ;
-        eg:favourite-number 2
-    ] .
-</pre>
-""" .
+	rdfs:comment "The state of an LV2 plugin instance." .
 
 state:mapPath
 	a lv2:Feature ;
-	rdfs:label "map file paths" ;
-	lv2:documentation """
-<p>This feature maps absolute paths to/from <q>abstract paths</q> which are
-stored in state.  To support this feature a host must pass an LV2_Feature with
-URI LV2_STATE__mapPath and data pointed to an LV2_State_Map_Path to the
-plugin's LV2_State_Interface methods.</p>
-
-<p>The plugin MUST map <em>all</em> paths stored in its state (including those
-inside any files in its state).  This is necessary to enable host to handle
-file system references correctly, e.g. for distribution or archival.</p>
-
-<p>For example, a plugin may write a path to a state file like so:</p>
-
-<pre class="c-code">
-void write_path(LV2_State_Map_Path* map_path, FILE* myfile, const char* path)
-{
-    char* abstract_path = map_path->abstract_path(map_path->handle, path);
-    fprintf(myfile, "%s", abstract_path);
-    free(abstract_path);
-}
-</pre>
-
-<p>Then, later reload the path like so:</p>
-
-<pre class="c-code">
-char* read_path(LV2_State_Map_Path* map_path, FILE* myfile)
-{
-    /* Obviously this is not production quality code! */
-    char abstract_path[1024];
-    fscanf(myfile, "%s", abstract_path);
-    return map_path->absolute_path(map_path->handle, abstract_path);
-}
-</pre>
-""" .
+	rdfs:label "map path" ;
+	rdfs:comment "A feature for mapping between absolute and abstract file paths." .
 
 state:makePath
 	a lv2:Feature ;
-	rdfs:label "create new file paths" ;
-	lv2:documentation """
-<p>This feature allows plugins to create new files and/or directories.  To
-support this feature the host passes an LV2_Feature with URI
-LV2_STATE__makePath and data pointed to an LV2_State_Make_Path to the plugin.
-The host may make this feature available only during save by passing it to
-LV2_State_Interface::save(), or available any time by passing it to
-LV2_Descriptor::instantiate().  If passed to LV2_State_Interface::save(), the
-feature MUST NOT be used beyond the scope of that call.</p>
-
-<p>The plugin is guaranteed a hierarchical namespace unique to that plugin
-instance, and may expect the returned path to have the requested path as a
-suffix.  There is <em>one</em> such namespace, even if the feature is passed to
-both LV2_Descriptor::instantiate() <em>and</em> LV2_State_Interface::save().
-Beyond this, the plugin MUST NOT make any assumptions about the returned
-paths.</p>
-
-<p>Like any other paths, the plugin MUST map these paths using state:mapPath
-before storing them in state.  The plugin MUST NOT assume these paths will be
-available across a save/restore otherwise, i.e.  only mapped paths saved to
-state are persistent, any other created paths are temporary.</p>
-
-<p>For example, a plugin may create a file in a subdirectory like so:</p>
-
-<pre class="c-code">
-char* save_myfile(LV2_State_Make_Path* make_path)
-{
-    char* path   = make_path->path(make_path->handle, "foo/bar/myfile.txt");
-    FILE* myfile = fopen(path, 'w');
-    fprintf(myfile, "I am some data");
-    fclose(myfile);
-    return path;
-}
-</pre>
-""" .
+	rdfs:label "make path" ;
+	rdfs:comment "A feature for creating new files and directories." .
 
 state:threadSafeRestore
 	a lv2:Feature ;
 	rdfs:label "thread-safe restore" ;
-	lv2:documentation """
-<p>If a plugin supports this feature, its LV2_State_Interface::restore method
-is thread-safe and may be called concurrently with audio class functions.</p>
-
-<p>To support this feature, the host MUST pass a <a
-href="worker.html#schedule">work:schedule</a> feature to the restore
-method, which will be used to complete the state restoration.  The usual
-mechanics of the worker apply: the host will call the plugin's work method,
-which emits a response which is later applied in the audio thread.</p>
-
-<p>The host is not required to block run() while restore() and work() load the
-state, so this feature allows state to be restored without dropouts.</p>
-""" .
+	rdfs:comment "A feature indicating support for thread-safe state restoration." .
 
 state:freePath
 	a lv2:Feature ;
-	rdfs:label "free a file path" ;
-	lv2:documentation """
-<p>This feature provides a function that can be used by plugins to free paths
-that were allocated by the host via other state features (state:mapPath and
-state:makePath).</p>
-""" .
+	rdfs:label "free path" ;
+	rdfs:comment "A feature for freeing paths allocated by the host." .
 
 state:Changed
 	a rdfs:Class ;
-	rdfs:label "State changed" ;
-	lv2:documentation """
-<p>A notification that the internal state of the plugin has been changed in a
-way that the host can not otherwise know about.</p>
-
-<p>This is a one-way notification, intended to be used as the type of an <a
-href="atom.html#Object">Object</a> sent from plugins when
-necessary.</p>
-
-<p>Plugins SHOULD emit such an event whenever a change has occurred that would
-result in a different state being saved, but not when the host explicity makes
-a change which it knows is likely to have that effect, such as changing a
-parameter.</p>
-""" .
+	rdfs:label "Changed" ;
+	rdfs:comment "A notification that the internal state of the plugin has changed." .