sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1705949 [2/3] - in /sis: branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/ branches/JDK8/core/sis-build-helper/src/main/resources/org/apache/sis/internal/book/ site/trunk/book/en/ site/trunk/book/fr/ site/trun...
Date Tue, 29 Sep 2015 23:21:58 GMT
Modified: sis/site/trunk/book/fr/geoapi.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geoapi.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geoapi.html (original)
+++ sis/site/trunk/book/fr/geoapi.html Tue Sep 29 23:21:57 2015
@@ -31,7 +31,7 @@
     </header>
     <p>
       Le projet <a href="http://www.geoapi.org">GeoAPI</a> offre un ensemble d’interfaces Java pour les applications géo-spatiales.
-      Dans une séries de paquets <code class="GeoAPI">org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
+      Dans une séries de paquets <code>org.opengis.*</code>, GeoAPI définit des structures représentant des méta-données,
       des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques.
       Dans une partie qui n’est pas encore standardisée — dénommée <i>pending</i> — GeoAPI définit des structures
       représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités.
@@ -74,7 +74,7 @@
         mais misaient plutôt — dans le cas du Java — sur la technologie <abbr>RMI</abbr> (<i>Remote Method Invocation</i>).
         Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de
         « <a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a> ».
-        Ces interfaces utilisaient déjà le nom de paquet <code class="GeoAPI">org.opengis</code>, qui sera adopté par GeoAPI.
+        Ces interfaces utilisaient déjà le nom de paquet <code>org.opengis</code>, qui sera adopté par GeoAPI.
       </p><p>
         En 2002, des développeurs de projets libres ont lancé un
         <a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
@@ -133,8 +133,8 @@
         </p>
         <div class="example"><p><b>Exemple:</b>
           Les schémas <abbr>XSD</abbr> des méta-données insèrent
-          un élément <code class="OGC">&lt;gmd:CI_Citation&gt;</code> à l’intérieur de <code class="OGC">&lt;gmd:citation&gt;</code>,
-          un élément <code class="OGC">&lt;gmd:CI_OnlineResource&gt;</code> à l’intérieur de <code class="OGC">&lt;gmd:onlineResource&gt;</code>,
+          un élément <code>&lt;gmd:CI_Citation&gt;</code> à l’intérieur de <code>&lt;gmd:citation&gt;</code>,
+          un élément <code>&lt;gmd:CI_OnlineResource&gt;</code> à l’intérieur de <code>&lt;gmd:onlineResource&gt;</code>,
           et ainsi de suite pour la centaine de classes définies dans le standard <abbr>ISO</abbr> 19115.
           Cette redondance n’est absolument pas nécessaire à un programme Java.
         </p></div>
@@ -143,16 +143,16 @@
         <p>
           Les standards de l’<abbr>OGC</abbr> utilisent des conventions de nommage qui sont différentes de celles du Java.
           En particulier les noms de presque toutes les classes de l’<abbr>OGC</abbr> commencent par un préfixe de deux lettres,
-          comme dans <code class="OGC">MD_Identifier</code>. Ces préfixes jouent le même rôle que les noms de paquets en Java.
+          comme dans <code>MD_Identifier</code>. Ces préfixes jouent le même rôle que les noms de paquets en Java.
           GeoAPI adapte cette pratique en utilisant des noms d’interfaces sans préfixes,
           et en plaçant ces interfaces dans des paquets correspondants aux préfixes mais avec des noms plus descriptifs.
           Occasionnellement nous changeons aussi les noms, par exemple pour éviter des acronymes
           ou pour se conformer à une convention établie telle que <i>Java beans</i>.
         </p>
         <div class="example"><p><b>Exemple:</b>
-          la classe <code class="OGC">MD_Identifier</code> de l’<abbr>OGC</abbr> devient
-          l’interface <code class="GeoAPI">Identifier</code> dans le paquet <code class="GeoAPI">org.opengis.metadata</code>.
-          La classe <code class="OGC">SC_CRS</code> de l’<abbr>OGC</abbr> devient l’interface <code class="GeoAPI">CoordinateReferenceSystem</code>,
+          la classe <code>MD_Identifier</code> de l’<abbr>OGC</abbr> devient
+          l’interface <code>Identifier</code> dans le paquet <code>org.opengis.metadata</code>.
+          La classe <code>SC_CRS</code> de l’<abbr>OGC</abbr> devient l’interface <code>CoordinateReferenceSystem</code>,
           et l’association <code class="OGC">usesDatum</code> devient une méthode <code class="GeoAPI">getDatum()</code> — et non pas
           « <code>getUsesDatum()</code> » comme aurait fait un outil de conversion automatique.
           Nous ne laissons pas des programmes appliquer aveuglement des règles qui ignorent les conventions de la communauté dont on traduit les schémas.
@@ -170,10 +170,10 @@
           Le standard <abbr>ISO</abbr> 19111 définit différents types de systèmes de coordonnées, tels que sphérique, cylindrique, polaire ou cartésien.
           Puis, il définit différents <em>sous-ensembles</em> de ces types de systèmes de coordonnées.
           Ces sous-ensembles, représentés par des unions, servent à spécifier qu’une classe peut être associée à seulement tel ou tel type de système de coordonnées.
-          Par exemple l’union des types pouvant être associés à une image, nommée <code class="OGC">CS_ImageCS</code>,
-          ne contient que <code class="OGC">CS_CartesianCS</code> et <code class="OGC">CS_AffineCS</code>.
+          Par exemple l’union des types pouvant être associés à une image, nommée <code>CS_ImageCS</code>,
+          ne contient que <code>CS_CartesianCS</code> et <code>CS_AffineCS</code>.
           Dans ce cas particulier, nous obtenons en Java l’effet souhaité par une modification de la hiérarchie des classes:
-          nous définissons l’interface <code class="GeoAPI">CartesianCS</code> comme une spécialisation de <code class="GeoAPI">AffineCS</code>, ce qui est sémantiquement correct.
+          nous définissons l’interface <code>CartesianCS</code> comme une spécialisation de <code>AffineCS</code>, ce qui est sémantiquement correct.
           Mais il n’est pas possible d’appliquer une stratégie similaire pour les autres unions sans violer la sémantique.
         </p></div>
       </li>
@@ -187,7 +187,7 @@
           structures représentant les systèmes de références des coordonnées (<abbr title="Coordinate Reference System">CRS</abbr>).
           Or ces derniers sont le sujet à part entière d’un autre standard: <abbr>ISO</abbr> 19111.
           D’ailleurs le standard <abbr>ISO</abbr> 19111:2007 stipule, dans sa section 3, qu’il réutilise tous les éléments
-          de <abbr>ISO</abbr> 19115 à l’exclusion de <code class="OGC">MD_CRS</code> et de ses composantes.
+          de <abbr>ISO</abbr> 19115 à l’exclusion de <code>MD_CRS</code> et de ses composantes.
           Les interfaces de GeoAPI réduisent la redondance en appliquant à l’ensemble du projet l’exclusion recommandée par <abbr>ISO</abbr> 19111.
         </p></div>
       </li>
@@ -203,8 +203,8 @@
           Ces méta-données ont été définies dans un standard séparé parce qu’elles n’ont pas été prêtes à temps pour la publication de la première partie du standard.
           Comme il n’était pas possible, pour des raisons administratives, d’ajouter des attributs dans les classes déjà publiées,
           les nouveaux attributs ont été ajoutées dans une sous-classe portant quasiment le même nom.
-          Ainsi, le standard <abbr>ISO</abbr> 19115-2 définit une classe <code class="OGC">MI_Band</code> qui étend la
-          classe <code class="OGC">MD_Band</code> du standard <abbr>ISO</abbr> 19115-1 en y ajoutant les attributs qui
+          Ainsi, le standard <abbr>ISO</abbr> 19115-2 définit une classe <code>MI_Band</code> qui étend la
+          classe <code>MD_Band</code> du standard <abbr>ISO</abbr> 19115-1 en y ajoutant les attributs qui
           auraient dû apparaître directement dans la classe parente s’ils avaient été prêts à temps.
           Dans GeoAPI, nous avons choisis de « réparer » ces anomalies en fusionnant ces deux classes en une seule interface.
         </p></div>
@@ -215,7 +215,7 @@
       Chaque mention d’un écart est aussi recopiée dans <a href="http://www.geoapi.org/3.0/javadoc/departures.html">une page unique</a>,
       pour donner une vue d’ensemble.
       Étant donné que ces écarts brouillent les liens qui existent entre les standards et certaines interfaces Java,
-      la correspondance entre ces langages est explicitée par des annotations <code class="GeoAPI">@UML</code>
+      la correspondance entre ces langages est explicitée par des annotations <code>@UML</code>
       et des fichiers de propriétés, décrits dans la section suivante.
     </p>
 
@@ -224,13 +224,13 @@
     <h3 id="UML-annotation">Correspondances explicitées par l’annotation <code>@UML</code></h3>
     <p>
       Pour chaque classe, méthode et constante définie à partir d’un standard <abbr>OGC</abbr> ou <abbr>ISO</abbr>,
-      GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code class="GeoAPI">org.opengis.annotation</code>.
-      En particulier l’annotation <code class="GeoAPI">@UML</code> indique le standard,
+      GeoAPI indique sa provenance à l’aide d’annotations définies dans le paquet <code>org.opengis.annotation</code>.
+      En particulier l’annotation <code>@UML</code> indique le standard,
       le nom de l’élément dans ce standard ainsi que son niveau d’obligation.
-      Par exemple dans l’extrait de code suivant, la première annotation <code class="GeoAPI">@UML</code> indique
-      que l’interface Java qui la suit (<code class="GeoAPI">ProjectedCRS</code>) est définie à partir du type
-      <code class="OGC">SC_ProjectedCRS</code> du standard <abbr>ISO</abbr> 19111.
-      La seconde annotation <code class="GeoAPI">@UML</code>, appliquée cette fois à la méthode
+      Par exemple dans l’extrait de code suivant, la première annotation <code>@UML</code> indique
+      que l’interface Java qui la suit (<code>ProjectedCRS</code>) est définie à partir du type
+      <code>SC_ProjectedCRS</code> du standard <abbr>ISO</abbr> 19111.
+      La seconde annotation <code>@UML</code>, appliquée cette fois à la méthode
       <code class="GeoAPI">getCoordinateSystem()</code>, indique que la méthode est définie
       à partir de l’association <code class="OGC">coordinateSystem</code> du standard <abbr>ISO</abbr> 19111,
       et que cette association est obligatoire — ce qui, traduit en Java, signifie que la méthode n’est
@@ -258,7 +258,7 @@ public interface ProjectedCRS extends Ge
       Les méthodes d’introspections du Java permettent d’accéder à ces informations pendant l’exécution d’une application.
       C’est utile pour obtenir les noms à afficher à des utilisateurs familiers avec les normes de l’<abbr>OGC</abbr>,
       ou pour écrire des éléments dans un document <abbr>XML</abbr>. L’exemple suivant affiche le nom standard de la
-      méthode <code class="GeoAPI">getTitle()</code> de l’interface <code class="GeoAPI">Citation</code>:
+      méthode <code class="GeoAPI">getTitle()</code> de l’interface <code>Citation</code>:
     </p>
 
 <pre>Class&lt;?&gt; type   = Citation.class;
@@ -268,15 +268,15 @@ String   id     = annot.identifier();
 System.out.println("Le nom standard de la méthode " + method.getName() + " est " + id);</pre>
 
     <p>
-      La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
+      La classe <code>org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
       <code class="SIS">getStandardName(Class)</code> pour effectuer cette opération.
     </p>
 
     <p>
       L’opération inverse — obtenir la classe et méthode Java d’un nom standard — est un peu plus lourde.
       Elle nécessite la lecture du fichier <code class="GeoAPI">class-index.properties</code> fournit dans le
-      paquet <code class="GeoAPI">org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
-      de rechercher le nom de l’interface correspondant à <code class="OGC">CI_Citation</code>.
+      paquet <code>org.opengis.annotation</code>. L’exemple suivant lit ce fichier juste avant
+      de rechercher le nom de l’interface correspondant à <code>CI_Citation</code>.
       Toutefois les utilisateurs sont encouragés à ne lire ce fichier qu’une fois et de conserver son contenu dans
       une cache de leur application.
     </p>
@@ -291,7 +291,7 @@ Class&lt;?&gt;  type = Class.forName(geo
 System.out.println("L’interface GeoAPI pour le type <abbr>ISO</abbr> " + isoName + " est " + type);</pre>
 
     <p>
-      La classe <code class="SIS">org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
+      La classe <code>org.apache.sis.util.iso.Types</code> fournit la méthode de commodité
       <code class="SIS">forStandardName(String)</code> pour effectuer cette opération.
     </p>
 
@@ -299,7 +299,7 @@ System.out.println("L’interface Geo
 
     <h3 id="MappingToJDK">Correspondances implicites avec le <abbr>JDK</abbr> standard</h3>
     <p>
-      Certaines classes et méthodes n’ont ni annotation <code class="GeoAPI">@UML</code>,
+      Certaines classes et méthodes n’ont ni annotation <code>@UML</code>,
       ni entrée dans le fichier <code class="GeoAPI">class-index.properties</code>.
       Il s’agit soit d’extensions de GeoAPI, ou soit de types définis dans d’autres bibliothèques,
       notamment le <abbr title="Java Development Kit">JDK</abbr> standard.
@@ -439,7 +439,7 @@ System.out.println("L’interface Geo
       <tr>
         <td><code class="OGC">CodeList</code></td>
         <td>(pas d’équivalent)</td>
-        <td class="leftBorder">Voir <code class="GeoAPI">org.opengis.util.CodeList</code> ci-dessous.</td>
+        <td class="leftBorder">Voir <code>org.opengis.util.CodeList</code> ci-dessous.</td>
       </tr>
       <tr>
         <td class="separator" colspan="2">Divers</td>
@@ -458,17 +458,17 @@ System.out.println("L’interface Geo
     </table>
 
     <p>
-      L’équivalent le plus direct de <code class="OGC">CharacterString</code> est la classe <code>String</code>,
-      mais GeoAPI emploie souvent l’interface <code class="GeoAPI">InternationalString</code> pour permettre au client de choisir la langue.
+      L’équivalent le plus direct de <code>CharacterString</code> est la classe <code>String</code>,
+      mais GeoAPI emploie souvent l’interface <code>InternationalString</code> pour permettre au client de choisir la langue.
       C’est utile par exemple sur un serveur fournissant simultanément des pages dans plusieurs langues.
       En reportant les traductions à l’utilisation des objets plutôt qu’au moment de leur création, on permet à la bibliothèque
-      <abbr>SIS</abbr> de fournir les mêmes instances de <code class="GeoAPI">Metadata</code>
-      ou <code class="GeoAPI">Coverage</code> (par exemple) pour les mêmes données peu importe la langue du client.
+      <abbr>SIS</abbr> de fournir les mêmes instances de <code>Metadata</code>
+      ou <code>Coverage</code> (par exemple) pour les mêmes données peu importe la langue du client.
       Les traductions peuvent être faites à la volée à l’aide d’un <code>ResourceBundle</code> de l’application,
-      ou être fournies directement avec les données (cas des <code class="GeoAPI">Metadata</code> notamment).
+      ou être fournies directement avec les données (cas des <code>Metadata</code> notamment).
     </p>
     <p>
-      Les <code class="OGC">Enumeration</code> correspondent aux <code>Enum</code> du Java.
+      Les <code>Enumeration</code> correspondent aux <code>Enum</code> du Java.
       Ils ont en commun de définir toutes les valeurs autorisées, sans permettre à l’utilisateur d’en ajouter.
       Les <code class="OGC">CodeList</code> sont similaires à ces énumérations, excepté que les utilisateurs peuvent y ajouter leurs propres éléments.
       Le <abbr>JDK</abbr> standard n’offrant pas cette possibilité,
@@ -486,15 +486,15 @@ assert MediumName.<code class="GeoAPI">v
 
     <h2 id="ServiceLoader">Obtenir une implémentation des interfaces</h2>
     <p>
-      GeoAPI définit des fabriques (<code class="GeoAPI">Factory</code>) permettant de créer des implémentations de ses interfaces.
-      Par exemple <code class="GeoAPI">DatumFactory</code> fournit des méthodes permettant de créer des instances
-      implémentant les interfaces du paquet <code class="GeoAPI">org.opengis.referencing.datum</code>.
-      Ces <code class="GeoAPI">Factory</code> doivent être implémentées par les bibliothèques géospatiales
+      GeoAPI définit des fabriques (<code>Factory</code>) permettant de créer des implémentations de ses interfaces.
+      Par exemple <code>DatumFactory</code> fournit des méthodes permettant de créer des instances
+      implémentant les interfaces du paquet <code>org.opengis.referencing.datum</code>.
+      Ces <code>Factory</code> doivent être implémentées par les bibliothèques géospatiales
       et déclarées comme <i>services</i> tel que défini par la classe standard <code>java.util.ServiceLoader</code>.
       La javadoc de <code>ServiceLoader</code> explique la façon de procéder.
       Mais pour résumer, les bibliothèques doivent créer dans le répertoire <code>META-INF/services/</code>
       un fichier dont le nom correspond au nom complet de l’interface de la fabrique
-      (<code class="GeoAPI">org.opengis.referencing.datum.DatumFactory</code> dans l’exemple précédent).
+      (<code>org.opengis.referencing.datum.DatumFactory</code> dans l’exemple précédent).
       Ce fichier texte doit contenir sur une ligne le nom complet de la classe implémentant cette interface.
       Il peut s’agir d’une classe cachée aux yeux des utilisateurs, car ils n’ont pas besoin de connaître son existence.
     </p>
@@ -532,7 +532,7 @@ public class MyApplication {
       et <cite>Système de <u>référence</u> des coordonnées</cite> (<abbr>CRS</abbr>).
       Un développeur qui lui non-plus ne souhaite pas faire cette distinction peut implémenter ces deux interfaces par la même classe.
       Il peut en résulter une implémentation dont la hiérarchie de classes est plus simple que la hiérarchie des interfaces de GeoAPI.
-      Le module <code class="GeoAPI">geoapi-examples</code>, discuté plus loin, fournit de telles combinaisons.
+      Le module <code>geoapi-examples</code>, discuté plus loin, fournit de telles combinaisons.
       Le tableau suivant énumère quelques combinaisons possibles:
     </p>
     <table>
@@ -542,43 +542,43 @@ public class MyApplication {
         <th>Usage</th>
       </tr>
       <tr>
-        <td><code class="GeoAPI">CoordinateReferenceSystem</code></td>
-        <td><code class="GeoAPI">CoordinateSystem</code></td>
+        <td><code>CoordinateReferenceSystem</code></td>
+        <td><code>CoordinateSystem</code></td>
         <td>Description d’un système de référence spatial (<abbr>CRS</abbr>).</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">GeodeticDatum</code></td>
-        <td><code class="GeoAPI">Ellipsoid</code></td>
+        <td><code>GeodeticDatum</code></td>
+        <td><code>Ellipsoid</code></td>
         <td>Description d’un référentiel geodétique.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">CoordinateOperation</code></td>
-        <td><code class="GeoAPI">MathTransform</code></td>
+        <td><code>CoordinateOperation</code></td>
+        <td><code>MathTransform</code></td>
         <td>Opération de transformation de coordonnées.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">IdentifiedObject</code></td>
-        <td><code class="GeoAPI">ReferenceIdentifier</code></td>
+        <td><code>IdentifiedObject</code></td>
+        <td><code>ReferenceIdentifier</code></td>
         <td>Objet (typiquement un <abbr>CRS</abbr>) que l’on peut identifier par un code.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">Citation</code></td>
-        <td><code class="GeoAPI">InternationalString</code></td>
+        <td><code>Citation</code></td>
+        <td><code>InternationalString</code></td>
         <td>Référence bibliographique composée d’un simple titre.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">GeographicBoundingBox</code></td>
-        <td><code class="GeoAPI">Extent</code></td>
+        <td><code>GeographicBoundingBox</code></td>
+        <td><code>Extent</code></td>
         <td>Étendue spatiale en degrés de longitude et de latitude.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">ParameterValue</code></td>
-        <td><code class="GeoAPI">ParameterDescriptor</code></td>
+        <td><code>ParameterValue</code></td>
+        <td><code>ParameterDescriptor</code></td>
         <td>Description d’un paramètre (nom, type) associée à sa valeur.</td>
       </tr>
       <tr>
-        <td><code class="GeoAPI">ParameterValueGroup</code></td>
-        <td><code class="GeoAPI">ParameterDescriptorGroup</code></td>
+        <td><code>ParameterValueGroup</code></td>
+        <td><code>ParameterDescriptorGroup</code></td>
         <td>Description d’un ensemble de paramètres associés à leurs valeurs.</td>
       </tr>
     </table>
@@ -587,63 +587,63 @@ public class MyApplication {
 
     <h2 id="GeoAPI-modules">Les modules de GeoAPI</h2>
     <p>
-      Le projet GeoAPI est composé d’une partie standardisée (<code class="GeoAPI">geoapi</code>) et
-      d’une partie expérimentale (<code class="GeoAPI">geoapi-pending</code>). Ces deux parties étant
+      Le projet GeoAPI est composé d’une partie standardisée (<code>geoapi</code>) et
+      d’une partie expérimentale (<code>geoapi-pending</code>). Ces deux parties étant
       mutuellement exclusives, les utilisateurs doivent veiller à ne pas les mélanger dans un même projet.
       Cette séparation est garantie pour tous les projets qui ne dépendent que du dépôt central de Maven
       (incluant les versions finales de Apache <abbr>SIS</abbr>),
-      car le module <code class="GeoAPI">geoapi-pending</code> n’est jamais déployé sur ce dépôt central.
-      En revanche certaines branches de développement de <abbr>SIS</abbr> peuvent dépendre de <code class="GeoAPI">geoapi-pending</code>.
+      car le module <code>geoapi-pending</code> n’est jamais déployé sur ce dépôt central.
+      En revanche certaines branches de développement de <abbr>SIS</abbr> peuvent dépendre de <code>geoapi-pending</code>.
     </p>
     <p>
       Les modules de GeoAPI sont:
     </p>
     <ul>
       <li><p>
-        <b><code class="GeoAPI">geoapi</code></b> — contient les interfaces couvertes par le
+        <b><code>geoapi</code></b> — contient les interfaces couvertes par le
         <a href="http://www.opengeospatial.org/standards/geoapi">standard GeoAPI de l’<abbr>OGC</abbr></a>.
         Les versions finales de Apache <abbr>SIS</abbr> dépendent de ce module.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-pending</code></b> — contient une
-        <em>copie</em> de toutes les interfaces du module <code class="GeoAPI">geoapi</code>
+        <b><code>geoapi-pending</code></b> — contient une
+        <em>copie</em> de toutes les interfaces du module <code>geoapi</code>
         (non pas une dépendance) avec des ajouts qui n’ont pas encore été approuvés comme un standard <abbr>OGC</abbr>.
-        Certains ajouts apparaissent dans des interfaces normalement définies par le module <code class="GeoAPI">geoapi</code>,
+        Certains ajouts apparaissent dans des interfaces normalement définies par le module <code>geoapi</code>,
         d’où la nécessité de les copier.
         Les branches de développement <code>jdk6</code>,
         <code>jdk7</code> et <code>jdk8</code> de Apache <abbr>SIS</abbr> dépendent de ce module,
-        mais cette dépendance est transformée en une dépendance vers le module <code class="GeoAPI">geoapi</code>
+        mais cette dépendance est transformée en une dépendance vers le module <code>geoapi</code>
         standard au moment de fusionner les branches avec le tronc.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-conformance</code></b> — contient
+        <b><code>geoapi-conformance</code></b> — contient
         une suite de tests JUnit que les développeurs peuvent utiliser pour tester leurs implémentations.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-examples</code></b> — contient des
+        <b><code>geoapi-examples</code></b> — contient des
         exemples d’implémentations relativement simples. Ces exemples sont placés dans le domaine public
         afin d’encourager les utilisateurs à les copier et les adapter à leurs besoins si les services
         de Apache <abbr>SIS</abbr> ne conviennent pas.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-proj4</code></b> — contient une
-        implémentation partielle des paquets <code class="GeoAPI">org.opengis.referencing</code>
+        <b><code>geoapi-proj4</code></b> — contient une
+        implémentation partielle des paquets <code>org.opengis.referencing</code>
         sous forme d’adaptateurs basés sur la bibliothèque C/C++ Proj.4.
-        Ce module peut être utilisé comme alternative au module <code class="SIS">sis-referencing</code>
+        Ce module peut être utilisé comme alternative au module <code>sis-referencing</code>
         pour certaines fonctions.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-netcdf</code></b> — contient une implémentation partielle des paquets
-        <code class="GeoAPI">org.opengis.referencing</code> et <code class="GeoAPI">org.opengis.coverage</code>
+        <b><code>geoapi-netcdf</code></b> — contient une implémentation partielle des paquets
+        <code>org.opengis.referencing</code> et <code>org.opengis.coverage</code>
         sous forme d’adaptateurs basés sur la bibliothèque <abbr>NetCDF</abbr> de l’<abbr>UCAR</abbr>.
         La suite de tests de ce module a été conçue de manière à être réutilisable par d’autres projets.
-        Apache <abbr>SIS</abbr> l’utilise pour tester son propre module <code class="SIS">sis-netcdf</code>.
+        Apache <abbr>SIS</abbr> l’utilise pour tester son propre module <code>sis-netcdf</code>.
       </p></li>
       <li><p>
-        <b><code class="GeoAPI">geoapi-openoffice</code></b> — contient
+        <b><code>geoapi-openoffice</code></b> — contient
         un <i>add-in</i> pour les suites bureautiques Libre/OpenOffice.org.
         <!--
-        Apache <abbr>SIS</abbr> offre son propre <i>add-in</i> dans le module <code class="SIS">sis-openoffice</code>,
+        Apache <abbr>SIS</abbr> offre son propre <i>add-in</i> dans le module <code>sis-openoffice</code>,
         mais utilise les mêmes noms de fonctions que le module de GeoAPI afin d’assurer une certaine compatibilité.
         -->
       </p></li>
@@ -651,7 +651,7 @@ public class MyApplication {
 
     <h3 id="GeoAPI-core">Les modules de définition des interfaces</h3>
     <p>
-      Les modules <code class="GeoAPI">geoapi</code> et <code class="GeoAPI">geoapi-pending</code>
+      Les modules <code>geoapi</code> et <code>geoapi-pending</code>
       fournissent les interfaces dérivées des schémas <abbr>UML</abbr> des standards internationaux.
       Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache <abbr>SIS</abbr>.
       On peut toutefois avoir un aperçu de son contenu en consultant la page listant les
@@ -662,14 +662,14 @@ public class MyApplication {
 
     <h3 id="GeoAPI-conformance">Le module de tests de conformité</h3>
     <p>
-      Le module <code class="GeoAPI">geoapi-conformance</code> fournit des <i>validateurs</i>, une <i>suite de tests</i> JUnit
+      Le module <code>geoapi-conformance</code> fournit des <i>validateurs</i>, une <i>suite de tests</i> JUnit
       et des <i>générateurs de rapports</i> sous forme de pages <abbr title="Hypertext Markup Language">HTML</abbr>.
       Ce module peut être utilisé avec n’importe quelle implémentation de GeoAPI.
       Pour les développeurs d’une bibliothèque géospatiale, il offre les avantages suivants:
     </p>
     <ul>
       <li>Réduire la fastidieuse tâche d’écriture des tests, en réutilisant des tests existants.</li>
-      <li>Accroître la confiance en la validité des tests, du fait que <code class="GeoAPI">geoapi-conformance</code>
+      <li>Accroître la confiance en la validité des tests, du fait que <code>geoapi-conformance</code>
           a lui-même sa propre suite de tests et est appliqué à d’autres implémentations.</li>
       <li>Faciliter la comparaison avec les autres implémentations.</li>
     </ul>
@@ -683,9 +683,9 @@ public class MyApplication {
       généralement décrites textuellement dans les spécifications abstraites ou dans la javadoc.
     </p>
     <div class="example"><p><b>Exemple:</b>
-      La conversion ou transformation d’une coordonnée (<code class="OGC">CC_CoordinateOperation</code>) peut nécessiter l’enchaînement de plusieurs étapes.
-      Dans une telle chaîne d’opérations (<code class="OGC">CC_ConcatenatedOperation</code>),
-      pour chaque étape (<code class="OGC">CC_SingleOperation</code>) le nombre de dimensions
+      La conversion ou transformation d’une coordonnée (<code>CC_CoordinateOperation</code>) peut nécessiter l’enchaînement de plusieurs étapes.
+      Dans une telle chaîne d’opérations (<code>CC_ConcatenatedOperation</code>),
+      pour chaque étape (<code>CC_SingleOperation</code>) le nombre de dimensions
       en sortie doit être égal au nombre de dimensions attendu en entré par l’opération suivante.
       Exprimée en langage Java, cette contrainte stipule que pour tout index
       0 &lt; <var>i</var> &lt; <var>n</var> où <var>n</var> est le nombre d’opérations, on a
@@ -694,7 +694,7 @@ public class MyApplication {
 
     <p>
       La façon la plus simple d’effectuer ces vérifications est d’appeler les méthodes statiques
-      <code class="GeoAPI">validate(…)</code> de la classe <code class="GeoAPI">org.opengis.test.Validators</code>.
+      <code class="GeoAPI">validate(…)</code> de la classe <code>org.opengis.test.Validators</code>.
       Ces méthodes portant toutes le même nom, il suffit d’écrire “<code>validate(<var>valeur</var>)</code>”
       et de laisser le compilateur choisir la méthode la plus appropriée en fonction du type d’objet donné en argument.
       Si le type d’objet n’est pas connu au moment de la compilation, alors la méthode <code class="GeoAPI">dispatch(Object)</code>
@@ -703,9 +703,9 @@ public class MyApplication {
     <p>
       Toutes les fonctions <code class="GeoAPI">validate(…)</code> suivent le fil des dépendances,
       c’est-à-dire qu’elles valideront aussi chaque composantes de l’objet à valider.
-      Par exemple la validation d’un objet <code class="GeoAPI">GeographicCRS</code> impliquera
-      la validation de sa composante <code class="GeoAPI">GeodeticDatum</code>, qui impliquera elle-même
-      la validation de sa composante <code class="GeoAPI">Ellipsoid</code>, et ainsi de suite.
+      Par exemple la validation d’un objet <code>GeographicCRS</code> impliquera
+      la validation de sa composante <code>GeodeticDatum</code>, qui impliquera elle-même
+      la validation de sa composante <code>Ellipsoid</code>, et ainsi de suite.
       Il est donc inutile de valider soi-même les composantes, à moins de vouloir isoler le test d’un élément souvent problématique.
     </p>
     <p>
@@ -768,10 +768,10 @@ public class MyTest {
 
     <h4 id="GeoAPI-tests">Exécution des tests pré-définis</h4>
     <p>
-      Des classes de tests JUnit sont définies dans des sous-paquets de <code class="GeoAPI">org.opengis.test</code>.
+      Des classes de tests JUnit sont définies dans des sous-paquets de <code>org.opengis.test</code>.
       Toutes les classes de tests portent un nom se terminant en "<code>Test</code>".
-      GeoAPI définie aussi une classe <code class="GeoAPI">org.opengis.test.TestSuite</code> englobant l’ensemble
-      des tests définis dans le module <code class="GeoAPI">geoapi-conformance</code>, mais Apache <abbr>SIS</abbr> ne l’utilise pas.
+      GeoAPI définie aussi une classe <code>org.opengis.test.TestSuite</code> englobant l’ensemble
+      des tests définis dans le module <code>geoapi-conformance</code>, mais Apache <abbr>SIS</abbr> ne l’utilise pas.
       Apache <abbr>SIS</abbr> hérite plutôt des classes <code class="GeoAPI">*Test</code> de GeoAPI au cas-par-cas, dans les modules appropriés.
       L’exemple ci-dessous donne un exemple de test de GeoAPI personnalisé.
       La <a href="http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/referencing/ParameterizedTransformTest.html">Javadoc
@@ -825,24 +825,24 @@ public class MyTest extends Parameterize
 
     <h3 id="GeoAPI-examples">Les modules d’exemples</h3>
     <p>
-      Le module <code class="GeoAPI">geoapi-examples</code> fournit des exemples d’implémentations simples.
+      Le module <code>geoapi-examples</code> fournit des exemples d’implémentations simples.
       Plusieurs de ces classes implémentent plus d’une interface à la fois afin de proposer un modèle conceptuel plus simple.
       La <a href="http://www.geoapi.org/geoapi-examples/apidocs/overview-summary.html">Javadoc de ce module</a>
       énumère les paquets et classes clés avec les combinaisons effectuées.
       Ce module illustre non-seulement comment GeoAPI peut-être implémenté, mais aussi comment l’implémentation
-      peut être testée en utilisant <code class="GeoAPI">geoapi-conformance</code>.
+      peut être testée en utilisant <code>geoapi-conformance</code>.
     </p>
     <p>
       Bien que sa mission première soit de servir d’inspiration aux implémenteurs,
-      <code class="GeoAPI">geoapi-examples</code> a tout-de-même été conçu de manière à être utilisable
+      <code>geoapi-examples</code> a tout-de-même été conçu de manière à être utilisable
       par des applications ayant des besoins très simples. Tous les exemples étant dans le domaine publique,
       les développeurs sont invités à adapter librement des copies de ces classes si nécessaires.
       Toutefois si des modifications sont apportées hors du cadre du projet GeoAPI, le bon usage veut que les copies
-      modifiées soient placées dans un paquet portant un autre nom que <code class="GeoAPI">org.opengis</code>.
+      modifiées soient placées dans un paquet portant un autre nom que <code>org.opengis</code>.
     </p>
     <p>
       Pour des besoins un peu plus poussés, les développeurs sont invités à examiner les modules
-      <code class="GeoAPI">geoapi-proj4</code> et <code class="GeoAPI">geoapi-netcdf</code>.
+      <code>geoapi-proj4</code> et <code>geoapi-netcdf</code>.
       Ces deux modules fournissent des exemples d’adaptateurs permettant d’utiliser, via les interfaces de GeoAPI,
       une partie des fonctionnalités de bibliothèques externes (Proj.4 et <abbr>NetCDF</abbr>).
       L’avantage de passer par ces interfaces est de disposer d’un modèle unifié pour exploiter deux <abbr>API</abbr> très différents,

Modified: sis/site/trunk/book/fr/geometry.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geometry.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geometry.html (original)
+++ sis/site/trunk/book/fr/geometry.html Tue Sep 29 23:21:57 2015
@@ -49,9 +49,9 @@
       On y retrouve toutefois des méthodes très similaires telles que <code class="GeoAPI">contains(…)</code> et <code class="GeoAPI">intersects(…)</code>.
     </p>
     <p>
-      Toutes les géométries sont des spécialisations de <code class="GeoAPI">TransfiniteSet</code>.
-      La classe parente de toutes ces géométries est appelée <code class="OGC">GM_Object</code> dans la norme <abbr>ISO</abbr> 19107.
-      Les interfaces de GeoAPI utilisent plutôt le nom <code class="GeoAPI">Geometry</code>, car l’omission du préfixe <code class="OGC">GM_</code>
+      Toutes les géométries sont des spécialisations de <code>TransfiniteSet</code>.
+      La classe parente de toutes ces géométries est appelée <code>GM_Object</code> dans la norme <abbr>ISO</abbr> 19107.
+      Les interfaces de GeoAPI utilisent plutôt le nom <code>Geometry</code>, car l’omission du préfixe <code class="OGC">GM_</code>
       (comme le veut la convention dans GeoAPI) aurait laissé un nom trop proche de la classe <code>Object</code> du Java.
     </p>
 
@@ -60,23 +60,21 @@
     <h3 id="DirectPosition">Points et positions directes</h3>
     <p>
       <abbr>ISO</abbr> 19107 définit deux types de structures pour représenter un point:
-      <code class="OGC">GM_Point</code> et <code class="OGC">DirectPosition</code>.
+      <code>GM_Point</code> et <code class="OGC">DirectPosition</code>.
       Le premier type est une véritable géométrie et peut donc être relativement lourd, selon les implémentations.
       Le second type n’est pas considéré formellement comme une géométrie;
-      il n’étend ni <code class="OGC">GM_Object</code> ni <code class="OGC">TransfiniteSet</code>.
+      il n’étend ni <code>GM_Object</code> ni <code class="OGC">TransfiniteSet</code>.
       Il ne définit pratiquement pas d’opérations autres que le stockage d’une séquence de nombres représentant une coordonnée.
       Il peut donc être un objet plus léger.
     </p>
     <p>
       Afin de permettre à l’<abbr>API</abbr> de travailler indifféremment avec ces deux types de positions,
       <abbr>ISO</abbr> 19107 définit <code class="OGC">Position</code> comme une <cite>union</cite> de
-      <code class="OGC">DirectPosition</code> et <code class="OGC">GM_Point</code>.
+      <code class="OGC">DirectPosition</code> et <code>GM_Point</code>.
       Il s’agit d’une union au sens du C/C++. Pour le langage Java, GeoAPI obtient le même effet en définissant
-      <code class="GeoAPI">Position</code> comme l’interface parente de
-      <code class="GeoAPI">DirectPosition</code> et <code class="GeoAPI">Point</code>.
-      Dans la pratique, la grande majorité des <abbr>API</abbr> de Apache <abbr>SIS</abbr> travaillent sur des
-      <code class="GeoAPI">DirectPosition</code>, ou occasionnellement des
-      <code class="GeoAPI">Position</code> quand il semble utile d’autoriser aussi des points géométriques.
+      <code>Position</code> comme l’interface parente de <code>DirectPosition</code> et <code>Point</code>.
+      Dans la pratique, la grande majorité des <abbr>API</abbr> de Apache <abbr>SIS</abbr> travaillent sur des <code>DirectPosition</code>,
+      ou occasionnellement des <code>Position</code> quand il semble utile d’autoriser aussi des points géométriques.
     </p>
 
 
@@ -159,7 +157,7 @@
       répétées tous les 360°, alors il doit lui-même ramener ses valeurs de longitudes entre -180° et 180° au préalable.
       Toutes les fonctions <code class="SIS">add(…)</code>, <code class="SIS">contains(…)</code>,
       <code class="SIS">intersect(…)</code>, <i>etc.</i> de toutes les enveloppes
-      définies dans le paquet <code class="SIS">org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
+      définies dans le paquet <code>org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
     </p>
     <aside>
       <h5>Généralisation à d’autres types d’axes</h5>
@@ -167,10 +165,9 @@
         Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
         Mais dans les enveloppes de Apache <abbr>SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
         Les caractéristiques de la plage de valeurs de chaque axe (ses extremums, unités, type de cycle, <i>etc.</i>)
-        sont des attributs des objets <code class="GeoAPI">CoordinateSystemAxis</code>,
-        indirectement associés aux enveloppes via le système de référence des coordonnées.
+        sont des attributs des objets <code>CoordinateSystemAxis</code>, indirectement associés aux enveloppes via le système de référence des coordonnées.
         Apache <abbr>SIS</abbr> inspecte ces attributs pour déterminer de quelle façon il doit effectuer ses opérations.
-        Ainsi, tout axe associé au code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code> bénéficiera du même traitement que la longitude.
+        Ainsi, tout axe associé au code <code>RangeMeaning.WRAPAROUND</code> bénéficiera du même traitement que la longitude.
         Cela pourrait être par exemple un axe du temps dans des données climatologiques
         (une “année” représentant la température moyenne de tous les mois de janvier, suivit de la moyenne de tous les mois de février,
         <i>etc.</i>).
@@ -183,10 +180,10 @@
       la même plage de valeurs. Ainsi, une enveloppe exprimant les longitudes dans la plage [-180 … +180]°
       n’est pas compatible avec une enveloppe exprimant les longitudes dans la plage [0 … 360]°.
       Les conversions, si nécessaires, sont à la charge de l’utilisateur
-      (la classe <code class="SIS">Envelopes</code> fournit des méthodes de commodités pour ce faire).
+      (la classe <code>Envelopes</code> fournit des méthodes de commodités pour ce faire).
       En outre, les coordonnées de l’enveloppe doivent être comprises dans les limites du système de coordonnées,
       sauf si le développeur souhaite volontairement considérer (par exemple) 300° de longitude
-      comme un position distincte de -60°. La classe <code class="SIS">GeneralEnvelope</code>
+      comme un position distincte de -60°. La classe <code>GeneralEnvelope</code>
       fournit une méthode <code class="SIS">normalize()</code> pour ramener les coordonnées
       dans les limites attendues, au prix parfois de valeurs <cite><i>lower</i></cite>
       supérieures à la valeur <cite><i>upper</i></cite>.
@@ -196,7 +193,7 @@
       <p>
         le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
         un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.
-        Mais dans les enveloppes de <abbr>SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
+        Mais dans les enveloppes de <abbr>SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code>RangeMeaning.WRAPAROUND</code>.
         Une enveloppe dont la plage est [0 … 0], [-0 … -0] ou [-0 … +0] sera bien considérée comme une enveloppe vide,
         mais la page [+0 … -0] sera au contraire considérée comme incluant la totalité des valeurs, jusqu’à l’infini.
         Ce comportement est conforme à la définition de <code class="SIS">lowerCorner</code> et <code class="SIS">upperCorner</code>

Modified: sis/site/trunk/book/fr/introduction.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/introduction.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/book/fr/introduction.html (original)
+++ sis/site/trunk/book/fr/introduction.html Tue Sep 29 23:21:57 2015
@@ -434,15 +434,15 @@
       <li>
         Les éléments définis dans un standard de l’<abbr title="Open Geospatial Consortium">OGC</abbr>
         ou de l’<abbr title="International Organization for Standardization">ISO</abbr> apparaissent en bleu.
-        Exemple: <code class="OGC">CD_Ellipsoid</code>.
+        Exemple: <code>CD_Ellipsoid</code>.
       </li>
       <li>
         Les éléments définis dans GeoAPI apparaissent en vert.
-        Exemple: <code class="GeoAPI">Ellipsoid</code>.
+        Exemple: <code>Ellipsoid</code>.
       </li>
       <li>
         Les éléments définis dans Apache <abbr title="Spatial Information System">SIS</abbr> apparaissent en brun.
-        Exemple: <code class="SIS">DefaultEllipsoid</code>.
+        Exemple: <code>DefaultEllipsoid</code>.
       </li>
       <li>
         Les autres éléments, notamment ceux du Java standard, sont laissés en noir.
@@ -464,7 +464,7 @@
       pour désigner l’ensemble des valeurs possibles en entrés et en sorties respectivement.
       Mais les fonctions auxquelles certains standards <abbr>ISO</abbr>
       les appliquent ne sont pas les mêmes que les fonctions auxquelles d’autres bibliothèques les appliquent.
-      Par exemple <abbr>ISO</abbr> 19123 applique ces termes aux objets <code class="OGC">CV_Coverage</code>,
+      Par exemple <abbr>ISO</abbr> 19123 applique ces termes aux objets <code>CV_Coverage</code>,
       vus comme des fonctions dont le domaine est l’ensemble des coordonnées spatio-temporelles de la couverture de données
       et le <i>range</i> l’ensemble des valeurs de la couverture.
       Mais la bibliothèque <abbr title="Network Common Data Form">NetCDF</abbr> de l’<abbr title="University Corporation for Atmospheric Research">UCAR</abbr>

Modified: sis/site/trunk/book/fr/utility.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/utility.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/book/fr/utility.html (original)
+++ sis/site/trunk/book/fr/utility.html Tue Sep 29 23:21:57 2015
@@ -67,7 +67,7 @@
     </p>
     <p>
       Afin de donner une certaine flexibilité aux développeurs, un grand nombre de classes de la bibliothèque <abbr>SIS</abbr>
-      implémentent l’interface <code class="SIS">org.apache.sis.util.LenientComparable</code>, qui défini une méthode <code class="SIS">equals(Object, ComparisonMode)</code>.
+      implémentent l’interface <code>org.apache.sis.util.LenientComparable</code>, qui défini une méthode <code class="SIS">equals(Object, ComparisonMode)</code>.
       Les principaux modes de comparaisons sont:
     </p>
     <ul>
@@ -124,26 +124,26 @@
       Mais c’est aussi le cas de d’autres classes moins évidentes comme
       <code>javax.imageio.ImageReader</code>/<code>ImageWriter</code> ainsi que les sous-classes de <code>Exception</code>.
       Lorsque une de ces classes est implémentée par <abbr>SIS</abbr>,
-      nous l’identifions en implémentant l’interface <code class="SIS">org.apache.sis.util.Localized</code>.
+      nous l’identifions en implémentant l’interface <code>org.apache.sis.util.Localized</code>.
       La méthode <code class="SIS">getLocale()</code> de cette interface permet alors de déterminer
       selon quelles conventions locales l’instance produira ses messages.
     </p>
     <p>
-      Certaines sous-classes de <code>Exception</code> définies par <abbr>SIS</abbr> implémentent aussi l’interface <code class="SIS">Localized</code>.
+      Certaines sous-classes de <code>Exception</code> définies par <abbr>SIS</abbr> implémentent aussi l’interface <code>Localized</code>.
       Pour ces exceptions, le message d’erreur peut être produit selon deux conventions locales selon qu’il s’adresse à l’administrateur du système ou au client:
       <code>getMessage()</code> retourne le message de l’exception selon les conventions par défaut du système, alors que
       <code>getLocalizedMessage()</code> retourne le message de l’exception selon les conventions locales spécifiées par <code class="SIS">getLocale()</code>.
-      Ce <code>Locale</code> sera lui-même déterminé par l’objet <code class="SIS">Localized</code> qui a lancé l’exception.
+      Ce <code>Locale</code> sera lui-même déterminé par l’objet <code>Localized</code> qui a lancé l’exception.
     </p>
     <div class="example"><p><b>Exemple:</b>
       Supposons que dans un environnement où la langue par défaut serait l’anglais,
-      un objet <code class="SIS">AngleFormat</code> est construit pour lire des angles selon les conventions françaises.
+      un objet <code>AngleFormat</code> est construit pour lire des angles selon les conventions françaises.
       Si une <code>ParseException</code> est lancée lors de l’utilisation de ce formateur,
       alors <code>getMessage()</code> retournera le message d’erreur en anglais
       tandis que <code>getLocalizedMessage()</code> retournera le message d’erreur en français.
     </p></div>
     <p>
-      Les exceptions définies par <abbr>SIS</abbr> n’implémentent pas toutes l’interface <code class="SIS">Localized</code>.
+      Les exceptions définies par <abbr>SIS</abbr> n’implémentent pas toutes l’interface <code>Localized</code>.
       Seules celles dont le message est le plus susceptible d’être montré à l’utilisateur sont ainsi localisées.
       Les <code>ParseException</code> sont de bonnes candidates puisqu’elles surviennent souvent
       suite à une saisie incorrecte du client. En revanche les <code>NullPointerException</code>
@@ -151,7 +151,7 @@
       elles peuvent être localisées dans la langue par défaut du système, mais ça sera généralement tout.
     </p>
     <p>
-      La classe utilitaire <code class="SIS">org.apache.sis.util.Exceptions</code> fournit
+      La classe utilitaire <code>org.apache.sis.util.Exceptions</code> fournit
       des méthodes de commodité pour obtenir des messages selon des conventions locales spécifiées
       lorsque cette information est disponible.
     </p>
@@ -161,7 +161,7 @@
     <h3 id="InternationalString">Instance unique pour toutes les conventions locales</h3>
     <p>
       Les <abbr>API</abbr> définit par <abbr>SIS</abbr> ou hérités de GeoAPI privilégient plutôt l’utilisation du type
-      <code class="GeoAPI">InternationalString</code> là où une valeur de type <code>String</code> serait susceptible d’être localisée.
+      <code>InternationalString</code> là où une valeur de type <code>String</code> serait susceptible d’être localisée.
       Cette approche permet de différer le processus d’internationalisation au moment d’obtenir
       une chaîne de caractères plutôt qu’au moment de construire l’objet qui les contient.
       C’est particulièrement utile pour les classes immutables qui serviront à créer des instances uniques
@@ -169,17 +169,17 @@
     </p>
     <div class="example"><p><b>Exemple:</b>
       Il existe dans <abbr>SIS</abbr> une seule instance de type
-      <code class="GeoAPI">OperationMethod</code> représentant la projection de Mercator, quelle que soit la langue du client.
+      <code>OperationMethod</code> représentant la projection de Mercator, quelle que soit la langue du client.
       Mais sa méthode <code class="GeoAPI">getName()</code> fournit (indirectement)
-      une instance de <code class="GeoAPI">InternationalString</code> telle que
+      une instance de <code>InternationalString</code> telle que
       <code>toString(Locale.ENGLISH)</code> retourne <cite>Mercator Projection</cite>
       alors que <code>toString(Locale.FRENCH)</code> retourne <cite>Projection de Mercator</cite>.
     </p></div>
     <p>
       En définissant des objets spatiaux indépendemment des conventions locales, on réduit les risques de sur-coûts de calculs.
       Par exemple il est plus facile de détecter que deux cartes emploient la même projection cartographique si cette dernière
-      est représentée par la même instance de <code class="GeoAPI">CoordinateOperation</code>, même si la projection
-      porte différents noms selon les pays. En outre, certain types de <code class="GeoAPI">CoordinateOperation</code>
+      est représentée par la même instance de <code>CoordinateOperation</code>, même si la projection
+      porte différents noms selon les pays. En outre, certain types de <code>CoordinateOperation</code>
       peuvent nécessiter des grilles de transformation de coordonnées, ce qui accroît l’intérêt de partager une instance unique
       pour des raisons d’économie de mémoire.
     </p>

Modified: sis/site/trunk/book/fr/xml.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/xml.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/book/fr/xml.html (original)
+++ sis/site/trunk/book/fr/xml.html Tue Sep 29 23:21:57 2015
@@ -54,7 +54,7 @@
       Les documents <abbr>XML</abbr> peuvent employer les préfixes de leur choix,
       mais les préfixes suivants sont couramment employés dans la pratique.
       Ils apparaissent donc par défaut dans les documents produits par Apache <abbr>SIS</abbr>.
-      Ces préfixes sont définis dans la classe <code class="SIS">org.apache.sis.xml.Namespaces</code>.
+      Ces préfixes sont définis dans la classe <code>org.apache.sis.xml.Namespaces</code>.
     </p>
     <table>
       <caption>Préfixes d’espaces de noms <abbr>XML</abbr> courants</caption>
@@ -63,27 +63,27 @@
         <th>Espace de nom</th>
       </tr>
       <tr>
-        <td><code class="OGC">gco</code></td>
+        <td><code>gco</code></td>
         <td><code>http://www.isotc211.org/2005/gco</code></td>
       </tr>
       <tr>
-        <td><code class="OGC">gfc</code></td>
+        <td><code>gfc</code></td>
         <td><code>http://www.isotc211.org/2005/gfc</code></td>
       </tr>
       <tr>
-        <td><code class="OGC">gmd</code></td>
+        <td><code>gmd</code></td>
         <td><code>http://www.isotc211.org/2005/gmd</code></td>
       </tr>
       <tr>
-        <td><code class="OGC">gmi</code></td>
+        <td><code>gmi</code></td>
         <td><code>http://www.isotc211.org/2005/gmi</code></td>
       </tr>
       <tr>
-        <td><code class="OGC">gmx</code></td>
+        <td><code>gmx</code></td>
         <td><code>http://www.isotc211.org/2005/gmx</code></td>
       </tr>
       <tr>
-        <td><code class="OGC">gml</code></td>
+        <td><code>gml</code></td>
         <td><code>http://www.opengis.net/gml/3.2</code></td>
       </tr>
       <tr>
@@ -125,18 +125,18 @@
     <h2 id="XML-ISO-19115">Représentation des méta-données selon <abbr>ISO</abbr> 19115-3</h2>
     <p>
       Pour chaque classe de méta-donnée, il existe un type <abbr>XML</abbr> portant le même nom que dans la spécification abstraite
-      (par exemple <code class="OGC">gmd:MD_Metadata</code> et <code class="OGC">gmd:CI_Citation</code>).
+      (par exemple <code>gmd:MD_Metadata</code> et <code>gmd:CI_Citation</code>).
       Tous ces types peuvent être employés comme racine d’un document <abbr>XML</abbr>.
-      Ainsi, il est possible d’écrire un document représentant un objet <code class="OGC">MD_Metadata</code> complet,
-      ou d’écrire un document représentant seulement un objet <code class="OGC">CI_Citation</code>.
+      Ainsi, il est possible d’écrire un document représentant un objet <code>MD_Metadata</code> complet,
+      ou d’écrire un document représentant seulement un objet <code>CI_Citation</code>.
     </p>
     <p>
       Le standard <abbr>ISO</abbr> 19139 dispose le contenu de ces objets d’une manière inhabituelle:
       pour chaque propriété dont le type de la valeur est lui-même une autre classe du standard <abbr>ISO</abbr> 19139,
       la valeur est enveloppée dans un élément qui représente son type plutôt que d’être écrite directement.
-      Par exemple dans un objet de type <code class="OGC">CI_Citation</code>,
+      Par exemple dans un objet de type <code>CI_Citation</code>,
       la valeur de la propriété <code class="OGC">citedResponsibleParty</code>
-      est enveloppée dans un élément <code class="OGC">CI_Responsibility</code>.
+      est enveloppée dans un élément <code>CI_Responsibility</code>.
       Cette pratique double la profondeur de l’arborescence, en introduisant une duplication
       à tous les niveaux pour chaque valeur, comme dans l’exemple suivant:
     </p>
@@ -179,15 +179,14 @@
       <li><p>
         Il y a d’abord le nom de la propriété, qui commence toujours par une lettre minuscule (en ignorant les préfixes).
         Dans les <abbr>API</abbr> Java, chaque propriété correspond à une méthode de la classe englobante.
-        Dans l’exemple ci-haut, <code class="OGC">gmd:identificationInfo</code>
-        (une propriété de la classe <code class="OGC">MD_Metadata</code>)
-        correspond à la méthode <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
+        Dans l’exemple ci-haut, <code>gmd:identificationInfo</code> (une propriété de la classe <code>MD_Metadata</code>)
+        correspond à la méthode <code>Metadata.getIdentificationInfo()</code>.
       </p></li>
       <li><p>
           Sous chaque propriété se trouve le type de la valeur, sauf si elle a été remplacée par une référence
           (la <a href="#gco-id">sous-section suivante</a> suivante approfondira ce sujet).
           Le type de la valeur est un élément <abbr>XML</abbr> dont le nom commence toujours par une lettre majuscule, en ignorant les préfixes.
-          Dans l’exemple ci-haut nous avions <code class="OGC">MD_DataIdentification</code>, qui correspond à l’interface Java <code class="GeoAPI">DataIdentification</code>.
+          Dans l’exemple ci-haut nous avions <code>MD_DataIdentification</code>, qui correspond à l’interface Java <code>DataIdentification</code>.
           C’est cet élément <abbr>XML</abbr> qui contient les valeurs de la propriété.
       </p></li>
     </ol>
@@ -205,7 +204,7 @@
     <aside>
       <h3>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></h3>
       <p>
-        Les paquets <code class="SIS">org.apache.sis.internal.jaxb.*</code> (non-publiques)
+        Les paquets <code>org.apache.sis.internal.jaxb.*</code> (non-publiques)
         définissent des adaptateurs <abbr>JAXB</abbr> pour tous les types d’objet <abbr>ISO</abbr>.
         Ces adaptateurs sont de toute façon nécessaires pour permettre à <abbr>JAXB</abbr>
         d’obtenir les classes <abbr>SIS</abbr> implémentant les interfaces de GeoAPI.
@@ -220,8 +219,8 @@
         un type dont le nom se termine par “<code class="OGC">_PropertyType</code>”.
         Pour le second groupe, chaque élément a un type dont le nom se termine par “<code class="OGC">_Type</code>”.
         Les “<code class="OGC">_PropertyType</code>” peuvent avoir un groupe d’attributs
-        (notamment <code class="OGC">gmd:idref</code>, <code class="OGC">gco:uuidref</code> et <code>xlink:href</code>)
-        que les schémas <abbr>XSD</abbr> nomment collectivement <code class="OGC">gco:ObjectReference</code>.
+        (notamment <code>gmd:idref</code>, <code>gco:uuidref</code> et <code>xlink:href</code>)
+        que les schémas <abbr>XSD</abbr> nomment collectivement <code>gco:ObjectReference</code>.
         Ces attributs n’ont pas de méthodes Java dédiées, mais sont accessibles indirectement via l’interface
         <code class="SIS">IdentifiedObject</code> décrite dans la sous-section suivante.
       </p>
@@ -279,34 +278,34 @@
     </ul>
     <p>
       Dans la bibliothèque <abbr>SIS</abbr>, tous les objets susceptibles d’être identifiés dans un document <abbr>XML</abbr>
-      implémentent l’interface <code class="SIS">org.apache.sis.xml.IdentifiedObject</code>.
+      implémentent l’interface <code>org.apache.sis.xml.IdentifiedObject</code>.
       Chaque instance de cette interface fournit une vue de ses identifiants sous forme de <code>Map&lt;Citation,String&gt;</code>,
-      dans lequel la clé <code class="GeoAPI">Citation</code> identifie le type d’identifiant et la valeur est l’identifiant lui-même.
-      Quelques constantes représentant différents types d’identifiants sont énumérées dans <code class="SIS">IdentifierSpace</code>,
+      dans lequel la clé <code>Citation</code> identifie le type d’identifiant et la valeur est l’identifiant lui-même.
+      Quelques constantes représentant différents types d’identifiants sont énumérées dans <code>IdentifierSpace</code>,
       notamment <code class="SIS">ID</code>, <code class="SIS">UUID</code> et <code class="SIS">HREF</code>.
       Chacune de ces clés peut être associée à une valeur d’un type différent (habituellement <code>String</code>,
       <code>UUID</code> ou <code>URI</code>) selon la clé.
       Par exemple le code suivant définit une valeur pour l’attribut <code class="OGC">uuid</code>:
     </p>
 
-<pre>import <code class="SIS">org.apache.sis.metadata.iso.DefaultMetadata</code>;
-import <code class="SIS">org.apache.sis.xml.IdentifierSpace</code>;
+<pre>import org.apache.sis.metadata.iso.DefaultMetadata;
+import org.apache.sis.xml.IdentifierSpace;
 import java.util.UUID;
 
 public class MyClass {
     public void myMethod() {
         UUID identifier = UUID.randomUUID();
         <code class="SIS">DefaultMetadata</code> metadata = new <code class="SIS">DefaultMetadata</code>();
-        metadata.<code class="SIS">getIdentifierMap().putSpecialized</code>(<code class="SIS">IdentifierSpace.UUID</code>, identifier);
+        metadata.<code class="SIS">getIdentifierMap().putSpecialized</code>(IdentifierSpace.UUID, identifier);
     }
 }</pre>
 
     <p>
       Bien que ce mécanisme aie été définit dans le but de mieux supporter les représentations des
-      attributs <abbr>XML</abbr> du groupe <code class="OGC">gco:ObjectIdentification</code>,
+      attributs <abbr>XML</abbr> du groupe <code>gco:ObjectIdentification</code>,
       il permet aussi de manière opportuniste de manipuler d’autres types d’identifiants.
       Par exemple les attributs <code class="GeoAPI">ISBN</code> et <code class="GeoAPI">ISSN</code>
-      de <code class="GeoAPI">Citation</code> peuvent être manipulés de cette manière.
+      de <code>Citation</code> peuvent être manipulés de cette manière.
       Les méthodes de l’interface <code class="SIS">IdentifiedObject</code> fournissent donc un endroit unique
       où peuvent être manipulés tous types d’identifiants (pas seulement <abbr>XML</abbr>) associés à un objet.
     </p>
@@ -324,21 +323,21 @@ public class MyClass {
       qu’elle ne peut pas être divulguée (<code class="OGC">withheld</code>), <i>etc.</i>
       La transmission de cette information nécessite l’utilisation d’un objet non-nul même lorsque la valeur est manquante.
       <abbr>SIS</abbr> procède en retournant un objet qui, en plus d’implémenter l’interface GeoAPI attendue,
-      implémente aussi l’interface <code class="SIS">org.apache.sis.xml.NilObject</code>.
+      implémente aussi l’interface <code>org.apache.sis.xml.NilObject</code>.
       Cette interface marque les instances dont toutes les méthodes retournent une collection vide,
       un tableau vide, <code>null</code>, <code>NaN</code>, <code>0</code> ou <code>false</code>,
       dans cet ordre de préférence selon ce que les types de retours des méthodes permettent.
-      Chaque instance implémentant <code class="SIS">NilObject</code> fournit une méthode
+      Chaque instance implémentant <code>NilObject</code> fournit une méthode
       <code class="SIS">getNilReason()</code> indiquant pourquoi l’objet est nul.
     </p>
     <p>
-      Dans l’exemple suivant, la partie gauche montre un élément <code class="OGC">CI_Citation</code>
-      contenant un élément <code class="OGC">CI_Series</code>, alors que dans la partie droite la série est inconnue.
-      Si l’élément <code class="OGC">CI_Series</code> avait été complètement omis,
-      alors la méthode <code class="GeoAPI">Citation.getSeries()</code> retournerait <code>null</code> en Java.
+      Dans l’exemple suivant, la partie gauche montre un élément <code>CI_Citation</code>
+      contenant un élément <code>CI_Series</code>, alors que dans la partie droite la série est inconnue.
+      Si l’élément <code>CI_Series</code> avait été complètement omis,
+      alors la méthode <code>Citation.getSeries()</code> retournerait <code>null</code> en Java.
       Mais en présence d’un attribut <code class="OGC">nilReason</code>, l’implémentation <abbr>SIS</abbr>
       de <code class="SIS">getSeries()</code> retournera plutôt un objet implémentant à la fois les interfaces
-      <code class="GeoAPI">Series</code> et <code class="SIS">NilReason</code>,
+      <code>Series</code> et <code class="SIS">NilReason</code>,
       et dont la méthode <code class="SIS">getNilReason()</code> retournera la constante <code class="SIS">UNKNOWN</code>.
     </p>
 

Modified: sis/site/trunk/content/book/en/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/en/developer-guide.html?rev=1705949&r1=1705948&r2=1705949&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html (original)
+++ sis/site/trunk/content/book/en/developer-guide.html Tue Sep 29 23:21:57 2015
@@ -287,56 +287,56 @@ Finally, GeoAPI packages will be introdu
 <td><abbr>ISO</abbr> 19103</td>
 <td/>
 <td><i>Conceptual schema language</i></td>
-<td><code>org.opengis.util</code></td>
-<td><code>org.apache.sis.util.iso</code></td>
+<td><code class="GeoAPI">org.opengis.util</code></td>
+<td><code class="SIS">org.apache.sis.util.iso</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19115</td>
 <td>Topic 11</td>
 <td><i>Metadata</i></td>
-<td><code>org.opengis.metadata</code></td>
-<td><code>org.apache.sis.metadata.iso</code></td>
+<td><code class="GeoAPI">org.opengis.metadata</code></td>
+<td><code class="SIS">org.apache.sis.metadata.iso</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19111</td>
 <td>Topic 2</td>
 <td><i>Spatial referencing by coordinates</i></td>
-<td><code>org.opengis.referencing</code></td>
-<td><code>org.apache.sis.referencing</code></td>
+<td><code class="GeoAPI">org.opengis.referencing</code></td>
+<td><code class="SIS">org.apache.sis.referencing</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19108</td>
 <td/>
 <td><i>Temporal Schema</i></td>
-<td><code>org.opengis.temporal</code></td>
+<td><code class="GeoAPI">org.opengis.temporal</code></td>
 <td/>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19107</td>
 <td>Topic 1</td>
 <td><i>Feature geometry</i></td>
-<td><code>org.opengis.geometry</code></td>
-<td><code>org.apache.sis.geometry</code></td>
+<td><code class="GeoAPI">org.opengis.geometry</code></td>
+<td><code class="SIS">org.apache.sis.geometry</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19101</td>
 <td>Topic 5</td>
 <td><i>Features</i></td>
-<td><code>org.opengis.feature</code></td>
-<td><code>org.apache.sis.feature</code></td>
+<td><code class="GeoAPI">org.opengis.feature</code></td>
+<td><code class="SIS">org.apache.sis.feature</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19123</td>
 <td>Topic 6</td>
 <td><i>Schema for coverage geometry and functions</i></td>
-<td><code>org.opengis.coverage</code></td>
-<td><code>org.apache.sis.coverage</code></td>
+<td><code class="GeoAPI">org.opengis.coverage</code></td>
+<td><code class="SIS">org.apache.sis.coverage</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 19156</td>
 <td>Topic 20</td>
 <td><i>Observations and measurements</i></td>
-<td><code>org.opengis.observation</code></td>
+<td><code class="GeoAPI">org.opengis.observation</code></td>
 <td/>
 </tr>
 <tr>
@@ -347,7 +347,7 @@ Finally, GeoAPI packages will be introdu
 <td/>
 <td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
 <td/>
-<td><code>org.apache.sis.xml</code></td>
+<td><code class="SIS">org.apache.sis.xml</code></td>
 </tr>
 <tr>
 <td><abbr>ISO</abbr> 13249</td>
@@ -360,21 +360,21 @@ Finally, GeoAPI packages will be introdu
 <td/>
 <td><s><abbr>OGC</abbr> 01-009</s></td>
 <td><s><i>Coordinate Transformation Services</i></s></td>
-<td><code>org.opengis.referencing</code></td>
-<td><code>org.apache.sis.referencing</code></td>
+<td><code class="GeoAPI">org.opengis.referencing</code></td>
+<td><code class="SIS">org.apache.sis.referencing</code></td>
 </tr>
 <tr>
 <td/>
 <td><s><abbr>OGC</abbr> 01-004</s></td>
 <td><s><i>Grid Coverage</i></s></td>
-<td><code>org.opengis.coverage</code></td>
-<td><code>org.apache.sis.coverage</code></td>
+<td><code class="GeoAPI">org.opengis.coverage</code></td>
+<td><code class="SIS">org.apache.sis.coverage</code></td>
 </tr>
 <tr>
 <td/>
 <td><abbr>SLD</abbr></td>
 <td><i>Styled Layer Descriptor</i></td>
-<td><code>org.opengis.style</code></td>
+<td><code class="GeoAPI">org.opengis.style</code></td>
 <td/>
 </tr>
 <tr>
@@ -509,7 +509,7 @@ in order to reduce the risk of confusion
 <li><a href="#GeoAPI-examples">Example Modules</a></li></ul></li></ul></nav>
 <p>
 The <a href="http://www.geoapi.org">GeoAPI</a> project offers a set of Java interfaces for geospatial applications.
-In a series of <code class="GeoAPI"> org.opengis.*</code> packages, GeoAPI defines structures representing metadata,
+In a series of <code class="GeoAPI">org.opengis.*</code> packages, GeoAPI defines structures representing metadata,
 coordinate reference systems and operations that perform cartographic projections.
 In a part that is not yet standardized — called <i>pending</i> — GeoAPI defines structures that represent geo-referenced images,
 geometries, filters that can be applied to queries, and other features.
@@ -694,7 +694,7 @@ the correspondence between these languag
 
 
 
-<h3 id="UML-annotation"><span class="section-number">2.1.1.</span> Mapping Given by <code>@UML</code> Annotations</h3>
+<h3 id="UML-annotation"><span class="section-number">2.1.1.</span> Mapping Given by <code class="GeoAPI">@UML</code> Annotations</h3>
 <p>
 For each class, method and constant defined by an <abbr title="Open Geospatial Consortium">OGC</abbr> or <abbr title="International Organization for Standardization">ISO</abbr> standard,
 GeoAPI indicates its provenance using annotations defined in the <code class="GeoAPI">org.opengis.annotation</code> package.
@@ -1099,7 +1099,7 @@ Apache <abbr>SIS</abbr> uses them to tes
 <li><p>
 <b><code class="GeoAPI">geoapi-openoffice</code></b> — contains an add-in for the OpenOffice.org office suite.
 <!--
-        Apache <abbr>SIS</abbr> offers its own add-in in the <code class="SIS">sis-openoffice</code> module,
+        Apache <abbr>SIS</abbr> offers its own add-in in the <code>sis-openoffice</code> module,
         but uses the same function names as the GeoAPI module in order to maintain some compatibility.
         -->
 </p></li>
@@ -1147,8 +1147,8 @@ is the number of operations, we have <co
 </p></div>
 
 <p>
-The easiest way to perform these verifications is to call the static methods <code class="GeoAPI">validate(…)</code> of the
-<code class="GeoAPI">org.opengis.test.Validators</code> class.
+The easiest way to perform these verifications is to call the static methods <code class="GeoAPI">validate(…)</code>
+of the <code class="GeoAPI">org.opengis.test.Validators</code> class.
 As all of <code class="GeoAPI">Validators</code> methods bear the same name, it is enough to write “<code>validate(<var>value</var>)</code>”
 and then let the compiler choose the most appropriate method for the type of object given in argument.
 If the object type is not known at the time of compilation,
@@ -1411,8 +1411,8 @@ or to write a document representing only
 for each property whose value type is itself another class of <abbr>ISO</abbr> 19115,
 the value is wrapped in an element that represents its type, rather than being written directly.
 For example, in an object of the <code class="OGC">CI_Citation</code> type,
-the value of the <code class="OGC">citedResponsibleParty</code> property is incorporated into a
-<code class="OGC">CI_Responsibility</code> element.
+the value of the <code class="OGC">citedResponsibleParty</code> property is incorporated
+into a <code class="OGC">CI_Responsibility</code> element.
 This practice doubles the depth of the hierarchy, and introduces duplication at all levels for each value,
 as in the following example:
 </p>
@@ -1549,8 +1549,8 @@ but someone must maintain a database pro
 </li>
 </ul>
 <p>
-In the <abbr title="Spatial Information System">SIS</abbr> library, all objects that can be identified in an <abbr>XML</abbr> document implements the
-<code class="SIS">org.apache.sis.xml.IdentifiedObject</code> interface.
+In the <abbr title="Spatial Information System">SIS</abbr> library, all objects that can be identified in an <abbr>XML</abbr> document
+implements the <code class="SIS">org.apache.sis.xml.IdentifiedObject</code> interface.
 Each instance of this interface provides a view of its identifiers in the form of a <code>Map&lt;Citation,String&gt;</code>,
 in which the <code class="GeoAPI">Citation</code> key indicates the type of identifier and the value is the identifier itself.
 Some constants representing different types of identifiers are listed in <code class="SIS">IdentifierSpace</code>,
@@ -1560,15 +1560,15 @@ Each of these keys may be associated wit
 For example, the following code defines a value for the <code class="OGC">uuid</code> attribute:
 </p>
 
-<pre><b>import</b> <code class="SIS">org.apache.sis.metadata.iso.DefaultMetadata</code>;
-<b>import</b> <code class="SIS">org.apache.sis.xml.IdentifierSpace</code>;
+<pre><b>import</b> org.apache.sis.metadata.iso.<code class="SIS">DefaultMetadata</code>;
+<b>import</b> org.apache.sis.xml.<code class="SIS">IdentifierSpace</code>;
 <b>import</b> java.util.UUID;
 
 <b>public</b> <b>class</b> MyClass {
     <b>public</b> <b>void</b> myMethod() {
         UUID identifier = UUID.randomUUID();
-        <code class="SIS">DefaultMetadata</code> metadata = <b>new</b> <code class="SIS">DefaultMetadata</code>();
-        metadata.<code class="SIS">getIdentifierMap().putSpecialized</code>(<code class="SIS">IdentifierSpace.UUID</code>, identifier);
+        <code class="SIS"><code class="SIS">DefaultMetadata</code></code> metadata = <b>new</b> <code class="SIS"><code class="SIS">DefaultMetadata</code></code>();
+        metadata.<code class="SIS">getIdentifierMap().putSpecialized</code>(<code class="SIS">IdentifierSpace</code>.UUID, identifier);
     }
 }</pre>
 
@@ -1594,8 +1594,8 @@ that the value probably exists but is no
 that the value cannot exist (<code class="OGC">missing</code>),
 or that the value cannot be revealed (<code class="OGC">withheld</code>), <i>etc.</i>
 The transmission of this information requires the use of a non-nul object, even when the value is missing.
-<abbr title="Spatial Information System">SIS</abbr> will then return an object that, besides implementing the desired GeoAPI interface, also implements the
-<code class="SIS">org.apache.sis.xml.NilObject</code> interface.
+<abbr title="Spatial Information System">SIS</abbr> will then return an object that, besides implementing the desired GeoAPI interface,
+also implements the <code class="SIS">org.apache.sis.xml.NilObject</code> interface.
 This interface flags the instances where all methods return an empty collection, an empty table, <code>null</code>,
 <code>NaN</code>, <code>0</code> or <code>false</code>, in this preference order, as permitted by the return types of the methods.
 Each instance that implements <code class="SIS">NilObject</code> provides a <code class="SIS">getNilReason()</code> method
@@ -2028,7 +2028,7 @@ However, the left and right positions ar
 This case is illustrated by the red rectangle in the figure below.
 </p>
 <center>
-<img alt="Exemples d’enveloppes avec et sans croisement de l’antiméridien." src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
+<img alt="Envelope example with and without anti-meridian spanning." src="../../apidocs/org/apache/sis/geometry/doc-files/AntiMeridian.png"/>
 </center>
 <p>
 The notions of inclusion and intersection, however, interpreted slightly differently in these two cases.



Mime
View raw message