Fix sphinx-build warnings - thanks to Ian Allen!

eng/users/source/managing_metadata/formatter/index.rst

@@ -11,10 +11,15 @@ The metadata.show service (the metadata viewer) displays a metadata document usi
 To this end the metadata.formatter.html and metadata.formatter.xml services allow an alternate stylesheet to be used for displaying the metadata.  The urls of interest to an end-user are:
 
  * /geonetwork/srv/<langCode>/metadata.formatter.html?xsl=<formatterId>&id=<metadataId>
+
   * Applies the stylesheet identified by xsl parameter to the metadata identified by id param and returns the document with the *html* contentType
+
  * /geonetwork/srv/<langCode>/metadata.formatter.xml?xsl=<formatterId>&id=<metadataId>
+
   * Applies the stylesheet identified by xsl parameter to the metadata identified by id param and returns the document with the *xml* contentType
+
  * /geonetwork/srv/<langCode>/metadata.formatter.list
+
   * Lists all of the metadata formatter ids
 
 Another use-case for metadata formatters is to embed the metadata in other websites.  Often a metadata document contains a very large amount of data and perhaps only a subset is interesting for a particular website or perhaps the branding/stylesheets needs to be customized to match the website.
@@ -49,37 +54,46 @@ If a zip file is uploaded the zip file must contain a file view.xsl.  The view.x
 
 The view.xsl stylesheet is executed on an xml file with essentially the following format:
 
-{{{
 - root 
+
  - url - text of the url tag is the base url to make requests to geonetwork.  An example is /geonetwork/
  - locUrl - text of the url tag is the localised url to make requests to geonetwork.  An example is /geonetwork/srv/eng/
- - resourceUrl - a base url for accessing a resource from the bundle.  An example of image tag might be:
+ - resourceUrl - a base url for accessing a resource from the bundle.  An example of image tag might be::
+
                  <img src="{/root/resourceURL}/img.png"/>
+
  - <metadata> - the root of the metadata document
  - loc
+
   - lang - the text of this tag is the lang code of the localization files that are loaded in this section
-  - <bundle loc file> - the contents of the bundles loc/<locale>/*.xml files
+  - <bundle loc file> - the contents of the bundles loc/<locale>/\*.xml files
+
  - strings - the contents of geonetwork/loc/<locale>/xml/strings.xml
  - schemas
+
   - <schema> - the name of the schema of the labels and codelists strings to come
+
    - labels - the localised labels for the schema as defined in the schema_plugins/<schema>/loc/<locale>/labels.xml
    - codelists - the localised codelists labels for the schema as defined in the schema_plugins/<schema>/loc/<locale>/codelists.xml
    - strings - the localised strings for the schema as defined in the schema_plugins/<schema>/loc/<locale>/strings.xml
-}}}
 
-If the view.xsl output needs to access resources in the formatter bundle (like css files or javascript files) the xml document contains a tag: resourceUrl that contains the url for obtaining that resource.  An example of an image tag is: {{{<img src="{/root/resourceURL}/img.png"/>}}}.
+If the view.xsl output needs to access resources in the formatter bundle (like css files or javascript files) the xml document contains a tag: resourceUrl that contains the url for obtaining that resource.  An example of an image tag is:: 
+
+ <img src="{/root/resourceURL}/img.png"/>
 
 By default the strings, labels, etc... will be localized based on the language provided in the URL.  For example if the url is /geonetwork/srv/eng/metadata.formatter.html?xsl=default&id=32 then the language code that is used to look up the localization will be eng.  However if the language code does not exist it will fall back to the Geonetwork platform default and then finally just load the first local it finds. 
 
-Schemas and geonetwork strings all have several different translations but extra strings, etc... can be added to the formatter bundle under the loc directory.  The structure would be:{{{loc/<langCode>/strings.xml}}}.  The name of the file does not have to be strings.xml.  All xml files in the loc/<langCode>/ directory will be loaded and added to the xml document.
+Schemas and geonetwork strings all have several different translations but extra strings, etc... can be added to the formatter bundle under the loc directory.  The structure would be::
+ 
+ loc/<langCode>/strings.xml
 
-The format of the formatter bundle is as follows:
+The name of the file does not have to be strings.xml.  All xml files in the loc/<langCode>/ directory will be loaded and added to the xml document.
 
-{{{
-config.properties
-view.xsl
-loc/<langCode>/
-}}}
+The format of the formatter bundle is as follows::
+ 
+ config.properties
+ view.xsl
+ loc/<langCode>/
 
 Only the view.xsl is required.  If a single xsl file is uploaded then the rest of the directory structure will be created and some files will be added with default values.  So a quick way to get started on a bundle is to upload an empty xsl file and then download it again.  The downloaded zip file will have the correct layout and contain any other optional files.
 
@@ -91,10 +105,13 @@ The config.properties file contains some configuration options used when creatin
  - *fixedLang* - sets the language of the strings to the fixed language, this ensures that the formatter will always use the same language for its labels, strings, etc... no matter what language code is in the url.
  - *loadGeonetworkStrings* - if true or non-existent then geonetwork strings will be added to the xml document before view.xsl is applied.  The default is true so if this parameter is not present then the strings will be loaded
  - *schemasToLoad* - defines which schema localization files should be loaded and added to the xml document before view.xsl is applied
+
   - if a comma separated list then only those schemas will be loaded
   - if all then all will be loaded
   - if none then no schemas will be loaded
+
  - *applicableSchemas* - declares which schemas the bundle can format
+
   - A comma separated list indicates specifically which schemas the bundle applies to
   - If the value is all (or value is empty) then all schemas are considered supported
 

eng/users/source/managing_metadata/harvesting/oaipmh/index.rst

@@ -27,11 +27,11 @@ Configuration options:
 
 - **Search criteria** - This allows you to select metadata records for harvest based on certain criteria: 
 
-    - *From* - You can provide a start date here. Any metadata whose last change date is equal to or greater than this date will be harvested. To add or edit a value for this field you need to use the icon alongside the text box. This field is optional so if you don't provide a start date the constraint is dropped. Use the icon to clear the field. 
-    - *Until* - Functions in the same way as the *From* parameter but adds an end constraint to the last change date search. Any metadata whose last change data is less than or equal to this data will be harvested.
-    - *Set* - An OAI-PMH server classifies metadata into sets (like categories in GeoNetwork). You can request all metadata records that belong to a set (and any of its subsets) by specifying the name of that set here.
-    - *Prefix* - 'Prefix' means metadata format. The oai_dc prefix must be supported by all OAI-PMH compliant servers. 
-    You can use the Add button to add more than one Search Criteria set. Search Criteria sets can be removed by clicking on the small cross at the top left of the set.
+  - *From* - You can provide a start date here. Any metadata whose last change date is equal to or greater than this date will be harvested. To add or edit a value for this field you need to use the icon alongside the text box. This field is optional so if you don't provide a start date the constraint is dropped. Use the icon to clear the field. 
+  - *Until* - Functions in the same way as the *From* parameter but adds an end constraint to the last change date search. Any metadata whose last change data is less than or equal to this data will be harvested.
+  - *Set* - An OAI-PMH server classifies metadata into sets (like categories in GeoNetwork). You can request all metadata records that belong to a set (and any of its subsets) by specifying the name of that set here.
+  - *Prefix* - 'Prefix' means metadata format. The oai_dc prefix must be supported by all OAI-PMH compliant servers. 
+  - You can use the Add button to add more than one Search Criteria set. Search Criteria sets can be removed by clicking on the small cross at the top left of the set.
 
 .. note:: the 'OAI provider sets' drop down next to the *Set* text box and the 'OAI provider prefixes' drop down next to the *Prefix* textbox are initially blank. After specifying the connection URL, you can press the **Retrieve Info** button, which will connect to the remote OAI-PMH server, retrieve all supported sets and prefixes and fill the drop downs with these values. Selecting a value from either of these drop downs will fill the appropriate text box with the selected value. 
 

eng/users/source/managing_metadata/harvesting/webdav/index.rst

@@ -41,5 +41,6 @@ Notes
 `````
 
 - The same metadata could be harvested several times by different instances of the WebDAV harvester. This is not good practise because copies of the same metadata record will have a different UUID.
+
 .. include:: ../common_notes.rst
 

eng/users/source/quickstartguide/installing/index.rst

@@ -72,10 +72,12 @@ The installer allows to install these additional packages:
 1. GeoNetwork User Interface: Experimental UI for GeoNetwork using javascript components based on ExtJs library.
 2. GeoServer: Web Map Server that provides default base layers for the GeoNetwork map viewer.
 3. European Union INSPIRE Directive configuration pack: Enables INSPIRE support in GeoNetwork.
+
  - INSPIRE validation rules.
  - Thesaurus files (GEMET, Inspire themes).
  - INSPIRE search panel.
  - INSPIRE metadata view.
+
 4. GAST: Installs GeoNetwork's Administrator Survival Tool. See :ref:`gast`.
 
 Installation using the platform independent installer
@@ -221,7 +223,7 @@ Choose a Database Connection Pool
 `````````````````````````````````
 To manage connections with the database efficiently, a database connection pool is used.  GeoNetwork uses the `Apache Database Connection Pool (DBCP) <http://commons.apache.org/dbcp/>`_. This connection pool can be configured directly in the config.xml file described below or in Jetty/tomcat through the Java Naming and Directory Interface (JNDI).
 
-- **ApacheDBCPool**: This pool is recommended for smaller catalogs (less than 10,000 records).
+* **ApacheDBCPool**: This pool is recommended for smaller catalogs (less than 10,000 records).
 * **JNDIPool**: This pool is configured in Jetty or Tomcat. It is recommended for larger catalogs (especially those with more than approx 30,000 records).
 
 More details about the DBCP configuration parameters that can be used here are in the advanced configuration section of this manual (See :ref:`Database_JNDI_configuration`).