Mark up documentation with lv2:documentation as per discussion on lv2-dev.

Use unified lv2plug.in style for ontology documentation.

1 files changed, 29 insertions, 30 deletions

diff --git a/extensions/ui.lv2/ui.ttl b/extensions/ui.lv2/ui.ttl
index 1c32272..36aee7f 100644
--- a/extensions/ui.lv2/ui.ttl
+++ b/extensions/ui.lv2/ui.ttl
@@ -33,8 +33,8 @@
     doap:license <http://usefulinc.com/doap/licenses/mit> ;
     doap:name    "LV2 UI" ;
     doap:release [
-        doap:revision "2" ;
-        doap:created "2010-05-10"
+        doap:revision "2.1pre1" ;
+        doap:created "2010-10-29"
     ] ;
     doap:maintainer [
         a foaf:Person ;
@@ -46,10 +46,11 @@
         foaf:homepage <http://drobilla.net/> ;
         rdfs:seeAlso  <http://drobilla.net/drobilla.rdf>
     ] ;
-    rdfs:comment """
+    lv2:documentation """
+<p>
 This extension defines an interface that can be used in LV2 plugins and hosts
 to create UIs for plugins. The UIs are similar to plugins and reside in shared object
-files in an LV2 bundle.  UIs are associated with a plugin in RDF using the triples
+files in an LV2 bundle.  UIs are associated with a plugin in RDF using the triples:</p>
 <pre>
 @prefix ui: &lt;http://lv2plug.in/ns/extensions/ui#&gt; .
 
@@ -57,25 +58,23 @@ files in an LV2 bundle.  UIs are associated with a plugin in RDF using the tripl
 &lt;http://my.pluginui&gt; a         ui:GtkUI ;
                      ui:binary &lt;myui.so&gt; .
 </pre>
-where &lt;http://my.plugin&gt; is the URI of the plugin,
+<p>where &lt;http://my.plugin&gt; is the URI of the plugin,
 &lt;http://my.pluginui&gt; is the URI of the plugin UI and &lt;myui.so&gt;
-is the relative URI to the shared object file.
+is the relative URI to the shared object file.</p>
 
-While it is possible to have the plugin UI and the plugin in the same shared
+<p>While it is possible to have the plugin UI and the plugin in the same shared
 object file it is probably a good idea to keep them separate so that hosts
 that don't want UIs don't have to load the UI code.  A UI MUST specify its
 class in the RDF data (ui:GtkUI in the above example). The class defines what
 type the UI is, e.g. what graphics toolkit it uses.  Any type of UI class can
-be defined separately from this extension.
-
-(Note: the prefix above is used throughout this file for the same URI)
+be defined separately from this extension.</p>
 
-It is possible to have multiple UIs for the same plugin, or to have the UI
+<p>It is possible to have multiple UIs for the same plugin, or to have the UI
 for a plugin in a different bundle from the actual plugin - this way people
 other than the plugin author can write plugin UIs independently without
-editing the original plugin bundle.
+editing the original plugin bundle.</p>
 
-Note that the process that loads the shared object file containing the UI
+<p>Note that the process that loads the shared object file containing the UI
 code and the process that loads the shared object file containing the actual
 plugin implementation are not necessarily the same process (and not even
 necessarily on the same machine).  This means that plugin and UI code can
@@ -84,39 +83,39 @@ the same objects in the UI and the actual plugin. The function callback
 interface defined in this header is the only method of communication between
 UIs and plugin instances (extensions may define more, though this is
 discouraged unless absolutely necessary since the significant benefits of
-network transparency and serialisability are lost).
+network transparency and serialisability are lost).</p>
 
-Since the LV2 specification itself allows for extensions that may add new
+<p>Since the LV2 specification itself allows for extensions that may add new
 functionality that could be useful to control with a UI, this extension
 allows for meta-extensions that can extend the interface between the UI and
 the host. These extensions mirror the extensions used for plugins - there are
-required and optional "features" that you declare in the RDF data for the UI as
+required and optional "features" that you declare in the RDF data for the UI:</p>
 <pre>
 &lt;http://my.pluginui&gt; lv2:requiredFeature &lt;http://my.feature&gt; .
 &lt;http://my.pluginui&gt; lv2:optionalFeature &lt;http://my.feature&gt; .
 </pre>
-The rules for a UI with a required or optional feature are identical to those
+<p>The rules for a UI with a required or optional feature are identical to those
 of lv2:Plugin instances: if a UI declares a feature as required, the host is
 NOT allowed to load it unless it supports that feature; and if it does support
 a feature, it MUST pass an appropriate LV2_Feature struct to the UI's
 instantiate() method.  These features may be used to specify how to pass
 specific types of data between the UI and the plugin port buffers
-(see LV2UI_Write_Function for details).
+(see LV2UI_Write_Function for details).</p>
 
-UIs written to this specification do not need to be threadsafe - the
+<p>UIs written to this specification do not need to be threadsafe - the
 functions defined below may only be called in the same thread the UI
-main loop is running in.
+main loop is running in.</p>
 
-Note that this UI extension is NOT a lv2:Feature. There is no way for a
+<p>Note that this UI extension is NOT a lv2:Feature. There is no way for a
 plugin to know whether the host that loads it supports UIs or not, and
 the plugin must always work without the UI (although it may be rather
 useless unless it has been configured using the UI in a previous session).
 From the plugin perspective, control from a UI is the same as control
-from anywhere else (e.g. the host, the user): via ports.
+from anywhere else (e.g. the host, the user): via ports.</p>
 
-A UI does not have to be a graphical widget, it could just as well be a
+<p>A UI does not have to be a graphical widget, it could just as well be a
 server listening for OSC input or an interface to some sort of hardware
-device, depending on the RDF class of the UI.
+device, depending on the RDF class of the UI.</p>
 """ .
 
 
@@ -133,17 +132,17 @@ and the host guarantees that the Gtk+ library has been initialised and the
 Glib main loop is running before an UI of this type is instantiated.""" .
 
 ui:makeSONameResident a lv2:Feature ;
-    rdfs:comment """
-This feature is ELF specific - it should only be used by UIs that
+    lv2:documentation """
+<p>This feature is ELF specific - it should only be used by UIs that
 use the ELF file format for the UI shared object files (e.g. on Linux).
 If it is required by an UI the UI should also list a number of SO names
 (shared object names) for libraries that the UI shared object
 depends on and that may not be unloaded during the lifetime of the host
-process, using the predicate @c ui:residentSONames, like this:
+process, using the predicate @c ui:residentSONames, like this:</p>
 <pre>
 &lt;http://my.pluginui&gt; ui:residentSONames "libgtkmm-2.4.so.1", "libfoo.so.0"
 </pre>
-The host MUST then make sure that the shared libraries with the given ELF
+<p>The host MUST then make sure that the shared libraries with the given ELF
 SO names are not unloaded when the plugin UI is, but stay loaded during
 the entire lifetime of the host process. On Linux this can be accomplished
 by calling dlopen() on the shared library file with that SO name and never
@@ -154,8 +153,8 @@ act as if the UI required the @c ui:makeResident feature instead. Thus
 the host only needs to find the shared library files corresponding to the
 given SO names if it wants to save RAM by unloading the UI shared object
 file when it is no longer needed. The data pointer for the LV2_Feature for
-this feature should always be set to NULL.
-"""^^lv2:basicXHTML .
+this feature should always be set to NULL.</p>
+""" .
 
 ui:noUserResize a lv2:Feature ;
     rdfs:comment """