fixing cross-references #72

docs/source/client.rst

@@ -20,7 +20,7 @@ why one might wish to write a client from scratch, not least as this
 allows you to use any programming language of your choice, or better
 integrate a CLAM webservice as a part of an existing application.
 
-The `RESTful API Specification <#restspec>`_ provides the full technical details necessary for an implementation of a
+The :ref:`restspec` provides the full technical details necessary for an implementation of a
 client. Moreover, each CLAM service offers an automatically tailored RESTful specification specific to the service, and
 example client code in Python, by pointing your browser to your service on the path ``/info/``.
 

docs/source/deployment.rst

@@ -9,7 +9,7 @@ The next step is to move it into production mode, i.e. the final deployment on a
     Running with the built-in development server is not recommended for production as it offers sub-optimal performance,
     scalability, and security.
 
-It is assumed you used the ``clamnewproject`` tool, as explained in `getting started <#gettingstarted>`_, to get
+It is assumed you used the ``clamnewproject`` tool, as explained in :ref:`gettingstarted`, to get
 started with your project. It generated various example configurations for production environments you can use.
 
 Amongst the generated scripts is a WSGI script (recognisable by the ``wsgi`` extension). WSGI is a calling convention
@@ -139,4 +139,4 @@ lighttpd), should work too.
 
 .. seealso::
 
-    For configuration authentication, see `the authentication section <#auth>`_ of the documentation.
+    For configuration of authentication, see :ref:`auth`.

docs/source/gettingstarted.rst

@@ -30,7 +30,7 @@ webservice.
 -  ``myfirstproject/myfirstproject.$HOSTNAME.yml`` - Host-specific
    external configution file which is automatically included from the
    service configuration file if ran on the specified host. This will be
-   addressed `later <#externalconf>`_.
+   addressed in :ref:`externalconf`.
 
 -  ``myfirstproject/myfirstproject_wrapper.py`` - System Wrapper Script
    in Python (this is recommended over the bash version, suited for more
@@ -63,7 +63,7 @@ Moreover, some scripts and sample configurations are generated:
    specific host), used for production environments
 
 -  ``*.conf`` - Sample configuration files for production environments
-   using a Apache 2 or Nginx webserver. Consult the section on `deployment <#deployment>`_ for details.
+   using a Apache 2 or Nginx webserver. Consult the section on :ref:`deployment` for details.
 
 These template files need to be edited for your particular application.
 They are heavily commented to guide you. The ``INSTRUCTIONS.rst`` file will
@@ -76,19 +76,19 @@ to direct your browser once the webservice is running.
 You can choose not to make use of one of the generated system wrapper
 scripts and instead either write one from scratch in another language of
 your choice, or directly let CLAM invoke your application. Moreover, a
-wrapper is intended for the project paradigm, the `action paradigm <#actions>`_ does
+wrapper is intended for the project paradigm, the action paradigm (:ref:`actions`) does
 not make use of it.
 
 Starting Your webservice
 ---------------------------
 
 You can start your webservice in development mode with the included ``startserver_development.sh`` script, but not
-before you first read how to construct your webservice. Read the the `service configuration <#serviceconfig>`_ documentation, and afterwards the `wrapper script <#wrapperscript>`_ documentation.
+before you first read how to construct your webservice. Read the :ref:`serviceconfig` documentation, and afterwards the :ref:`wrapperscript` documentation.
 
 The start script simply installs your webservice and runs ``clamservice`` to run it, passing the module name of your
 webservice configuration. Make sure you first activated your Python virtual environment (if used) when calling the start script.
 
-For production environments, read the documentation on `deployment <#deployment>`_.
+For production environments, read the documentation on :ref:`deployment`.
 
 Overriding host, port and urlprefix (advanced)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/source/index.rst

@@ -139,23 +139,23 @@ CLAM presents two different paradigms for wrapping your script or
 application. The second is a new addition since CLAM 0.9.11 . You may
 use either or both at the same time.
 
-#. `Project Paradigm <#project>`_ – Users create projects, upload files with
+#. :ref:`project <Project Paradigm>` – Users create projects, upload files with
    optional parameters to those projects, and subsequently start the
    project, optionally passing global parameters to the system. The
    system may run for a long time and may do batch-processing on
    multiple input files.
 
-#. `Action Paradigm <#actions>`_ – This is a more limited, and simple
+#. :ref:`actions <Action Paradigm>` – This is a more limited, and simple
    remote-procedure call mechanism. Users interact in real-time with the
    service on specific URLs, passing parameters. Unlike the project
    paradigm, this is not suitable for complex operations on big-data.
 
 A CLAM webservice needs the following three components from the service
 developer:
 
-#. A `service configuration <#serviceconfiguration>`_
+#. A :ref:`serviceconfig`
 
-#. A `wrapper script <#wrapperscript>`_ for your command line application;
+#. A :ref:`wrapperscript`` for your command line application;
 
 #. A command line application (your NLP tool)
 

docs/source/serviceconfiguration.rst

@@ -12,11 +12,9 @@ is not essential for you to be able to make your own service
 configurations.
 
 It is recommended, but not mandatory, to separate the parts of the configuration that are host-specific configuration
-settings from the parts that are generic. The host-specific configuration is stored in an `external configuration file
-<#externalconf>`_ that is dynamically included from the service configuration script. Doing so facilitates
-distribution and deployment on different systems late.
+settings from the parts that are generic. Host-specific configurations is stored in :ref:`externalconf` that are dynamically included from the service configuration script. Doing so facilitates distribution and deployment on different systems late.
 
-It is assumed you are using the ``clamnewproject`` tool as explain in `getting started <#gettingstarted>`_, which
+It is assumed you are using the ``clamnewproject`` tool as explain in :ref:`gettingstarted`, which
 generates a template service configuration you can edit, including a host-specific external configuration name
 recognisable by the ``yml`` extension. When reading this section, it may help your understanding to inspect these files
 alongside.
@@ -36,7 +34,7 @@ Server Administration
 The host-specific part of the configuration contains first of all the hostname and the port where the webservice will be
 hosted. If not configured, automatic detection is attempted.
 
-When CLAM runs in a production environment (see `deployment <#deployment>`) using an existing webserver without its
+When CLAM runs in a production environment (see :ref:`deployment`) using an existing webserver without its
 own virtual host, it is often configured at a different URL rather than at the webserver root. In this case, the value
 of ``URLPREFIX`` should be configured accordingly. If you want your webservice to run at
 http://yourhost.com/yourwebservice/ for instance, then the ``URLPREFIX`` should be set to ``yourwebservice``.
@@ -166,7 +164,7 @@ You can mark certain users as being administrators using the ``ADMINS``
 list. Administrators can see and modify all projects.
 
 The ability to view and set parameters can be restricted to certain users. You can use the extra parameter options
-``allowusers=`` or ``denyusers=`` to set this. See the documentation on `parameter configuration <#parameters>`_. A
+``allowusers=`` or ``denyusers=`` to set this. See the documentation on :ref:`parameters`. A
 common use would be to define one user to be the guest user, for instance the user named “guest”, and set
 ``denyusers=[’guest’]`` on the parameters you do not want the guest user to use.
 
@@ -514,8 +512,7 @@ if that is the case. These definitions are made in so-called *profiles*.
 A profile defines *input templates* and *output templates*. The input
 templates and output template can be seen as “slots” for certain
 filetypes and metadata. An analogy from childhood memory may facilitate
-understanding this, as shown and explained in
-Figure \ `2.2 <#fig:blokkendoos>`__.
+understanding this, as shown and explained in the figure below:
 
 .. figure:: blokkendoos.jpg
    :alt: Box and blocks analogy from childhood memory: the holes on one
@@ -723,7 +720,7 @@ The definition for :class:`InputTemplate` takes three mandatory arguments:
    its selection menus.
 
 After the three mandatory arguments, you may specify any of the Parameter types to indicate the accepted/required
-metadata for the particular input templates. Use any of the `parameter types <#parameters>`_ .  We will come to an
+metadata for the particular input templates. Use any of the parameter types (see :ref:`parameters`) .  We will come to an
 example of this soon.
 
 After specifying any such parameters, there are some possible keyword
@@ -742,7 +739,7 @@ arguments:
    ``unique=False``, insert the variable ``$SEQNR`` into the filename,
    which will be replaced by a number in sequence. After all, we cannot
    have multiple files with the same name. As explained in
-   `later on <#filenamevariables>`__, you can also use any of
+   :ref:`filenamevariables`, you can also use any of
    the metadata parameters as variable in the filename.
 
 #. ``extension`` – Files uploaded through this input template are
@@ -1269,6 +1266,9 @@ web-interface:
 -  ``preselectinputtemplate`` – Pre-select the first defined input
    template as default inputtemplate.
 
+
+.. _actions:
+
 Actions
 ---------
 

docs/source/wrapperscript.rst

@@ -10,8 +10,7 @@ Application itself to be totally independent of CLAM.
 
 When CLAM starts the wrapper script, it creates a ``clam.xml`` file containing the selection of parameters and input
 files provided by the user.  It call the wrapper script with the arguments as specified in ``COMMAND`` in
-the service configuration file (see `here <#command>`_).
-There are some important things to take into account:
+the :ref:`serviceconf`. There are some important things to take into account:
 
 -  All user-provided input has to be read from the specified input
    directory. A full listing of this input will be provided in the