Move documentation to metadata files and convert it to Markdown

2 files changed, 82 insertions, 68 deletions

diff --git a/lv2/dynmanifest/dynmanifest.meta.ttl b/lv2/dynmanifest/dynmanifest.meta.ttl
index 77f03ca..7527494 100644
--- a/lv2/dynmanifest/dynmanifest.meta.ttl
+++ b/lv2/dynmanifest/dynmanifest.meta.ttl
@@ -1,6 +1,8 @@
 @prefix dcs: <http://ontologi.es/doap-changeset#> .
+@prefix dman: <http://lv2plug.in/ns/ext/dynmanifest#> .
 @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#> .
 
 <http://lv2plug.in/ns/ext/dynmanifest>
@@ -9,7 +11,7 @@
 	doap:name "LV2 Dynamic Manifest" ;
 	doap:homepage <http://naspro.atheme.org> ;
 	doap:created "2009-06-13" ;
-	doap:shortdesc "Support for dynamic data generation." ;
+	doap:shortdesc "Support for dynamic manifest data generation." ;
 	doap:programming-language "C" ;
 	doap:developer <http://lv2plug.in/ns/meta#daste> ;
 	doap:release [
@@ -52,5 +54,78 @@
 				rdfs:label "Initial release."
 			]
 		]
-	] .
+	] ;
+	lv2:documentation """
+
+The LV2 API, on its own, cannot be used to write plugin libraries where data is
+dynamically generated at runtime (e.g. API wrappers), since LV2 requires needed
+information to be provided in one or more static data (RDF) files. This API
+addresses this limitation by extending the LV2 API.
+
+To detect that a plugin library implements a dynamic manifest generator, the
+host checks its static manifest for a description like:
+
+    :::turtle
+    <http://example.org/my-dynamic-manifest>
+        a dman:DynManifest ;
+        lv2:binary <mydynmanifest.so> .
+
+To load the data, the host loads the library (e.g. `mydynmanifest.so`) as usual
+and fetches the dynamic Turtle data from it using this API.
+
+The host is allowed to request regeneration of the dynamic manifest multiple
+times, and the plugin library is expected to provide updated data if/when
+possible. All data and references provided via this API before the last
+regeneration of the dynamic manifest is to be considered invalid by the host,
+including plugin descriptors whose URIs were discovered using this API.
+
+### Accessing Data
+
+To access data using this API, the host must:
+
+  1. Call lv2_dyn_manifest_open().
+
+  2. Create a `FILE` for functions to write data to (for example with `tmpfile()`).
+
+  3. Get a list of exposed subject URIs using lv2_dyn_manifest_get_subjects().
+
+  4. Call lv2_dyn_manifest_get_data() for each URI of interest to write the
+  related data to the file.
+
+  5. Call lv2_dyn_manifest_close().
+
+  6. Parse the content of the file(s).
+
+  7. Remove the file(s).
+
+Each call to the above mentioned dynamic manifest functions MUST write a
+complete, valid Turtle document (including all needed prefix definitions) to
+the output FILE.
+
+Each call to lv2_dyn_manifest_open() causes the (re)generation of the dynamic
+manifest data, and invalidates all data fetched before the call.
+
+In case the plugin library uses this same API to access other dynamic
+manifests, it MUST implement some mechanism to avoid potentially endless loops
+(such as A loads B, B loads A, etc.) and, in case such a loop is detected, the
+operation MUST fail.  For this purpose, use of a static boolean flag is
+suggested.
+
+### Threading Rules
+
+All of the functions defined by this specification belong to the Discovery
+class.
+
+
+"""^^lv2:Markdown .
+
+dman:DynManifest
+	lv2:documentation """
+
+There MUST NOT be any instances of dman:DynManifest in the generated manifest.
+
+All relative URIs in the generated data MUST be relative to the base path that
+would be used to parse a normal LV2 manifest (the bundle path).
+
+"""^^lv2:Markdown .
 
diff --git a/lv2/dynmanifest/dynmanifest.ttl b/lv2/dynmanifest/dynmanifest.ttl
index caa2a08..c93120f 100644
--- a/lv2/dynmanifest/dynmanifest.ttl
+++ b/lv2/dynmanifest/dynmanifest.ttl
@@ -7,67 +7,10 @@
 
 <http://lv2plug.in/ns/ext/dynmanifest>
 	a lv2:Specification ;
+	rdfs:label "LV2 Dyn Manifest" ;
+	rdfs:comment "Support for dynamic manifest data generation." ;
 	rdfs:seeAlso <dynmanifest.h> ,
-		<dynmanifest.meta.ttl> ;
-	lv2:documentation """
-<p>The LV2 API, on its own, cannot be used to write plugin libraries where data
-is dynamically generated at runtime (e.g. API wrappers), since LV2 requires
-needed information to be provided in one or more static data (RDF) files. This
-API addresses this limitation by extending the LV2 API.</p>
-
-<p>To detect that a plugin library implements a dynamic manifest generator,
-the host checks its static manifest for a description like:</p>
-
-<pre class="turtle-code">
-&lt;http://example.org/my-dynamic-manifest&gt;
-    a dman:DynManifest ;
-    lv2:binary &lt;mydynmanifest.so&gt; .
-</pre>
-
-<p>To load the data, the host loads the library
-(e.g. <code>mydynmanifest.so</code>) as usual and fetches the dynamic Turtle
-data from it using this API.</p>
-
-<p>The host is allowed to request regeneration of the dynamic manifest multiple
-times, and the plugin library is expected to provide updated data if/when
-possible.  All data and references provided via this API before the last
-regeneration of the dynamic manifest is to be considered invalid by the host,
-including plugin descriptors whose URIs were discovered using this API.</p>
-
-<h3>Accessing Data</h3>
-
-<p>Whenever a host wants to access data using this API, it could:</p>
-
-<ol>
-<li>Call lv2_dyn_manifest_open().</li>
-<li>Create a FILE for functions to write data to (e.g. using tmpfile()).</li>
-<li>Get a <q>list</q> of exposed subject URIs using
-    lv2_dyn_manifest_get_subjects().</li>
-<li>Call lv2_dyn_manifest_get_data() for each URI of interest to
-    get the data related to that URI (which can be written to any FILE).</li>
-<li>Call lv2_dyn_manifest_close().</li>
-<li>Parse the content of the FILE(s).</li>
-<li>Free/delete/unlink the FILE(s).</li>
-</ol>
-
-<p>Each call to the above mentioned dynamic manifest functions MUST write a
-complete, valid Turtle document (including all needed prefix definitions) to
-the output FILE.</p>
-
-<p>Each call to lv2_dyn_manifest_open() causes the (re)generation of the
-dynamic manifest data, and invalidates all data fetched before the call.</p>
-
-<p>In case the plugin library uses this same API to access other dynamic
-manifests, it MUST implement some mechanism to avoid potentially endless loops
-(such as A loads B, B loads A, etc.) and, in case such a loop is detected, the
-operation MUST fail.  For this purpose, use of a static boolean flag is
-suggested.</p>
-
-<h3>Threading Rules</h3>
-
-<p>All of the functions defined by this specification belong to the Discovery
-class.</p>
-""" .
+		<dynmanifest.meta.ttl> .
 
 dman:DynManifest
 	a rdfs:Class ;
@@ -76,11 +19,7 @@ dman:DynManifest
 		a owl:Restriction ;
 		owl:onProperty lv2:binary ;
 		owl:minCardinality 1 ;
-		rdfs:comment "A DynManifest MUST have at least 1 lv2:binary, which MUST implement all the functions defined in dynmanifest.h."
+		rdfs:comment "A DynManifest MUST have at least one lv2:binary."
 	] ;
-	rdfs:comment """The class which represents a dynamic manifest generator.
-
-There MUST NOT be any instances of dman:DynManifest in the generated manifest.
-
-All relative URIs in the generated data MUST be relative to the base path that would be used to parse a normal LV2 manifest (the bundle path).""" .
+	rdfs:comment "Dynamic manifest for an LV2 binary." .