sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1794573 [10/10] - in /sis/site/trunk/book: en/ fr/
Date Tue, 09 May 2017 13:09:59 GMT
Modified: sis/site/trunk/book/fr/utility.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/utility.html?rev=1794573&r1=1794572&r2=1794573&view=diff
==============================================================================
--- sis/site/trunk/book/fr/utility.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/utility.html [UTF-8] Tue May  9 13:09:58 2017
@@ -31,307 +31,311 @@
       Content below this point is copied in "../../content/book/fr/developer-guide.html"
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
-    <header>
-      <h1 id="Utilities">Classes et méthodes utilitaires</h1>
-    </header>
-    <p>
-      Ce chapitre décrit des aspects de Apache <abbr>SIS</abbr> qui s’appliquent à l’ensemble de la bibliothèque.
-      La plupart de ces utilitaires ne sont pas spécifiques aux systèmes d’information spatiales.
-    </p>
-
-    <h2 id="ComparisonMode">Modes de comparaisons des objets</h2>
-    <p>
-      Il existe différentes opinions sur la façon d’implémenter la méthode <code>Object.equals(Object)</code> du Java standard.
-      Selon certains, il doit être possible de comparer différentes implémentations d’une même interface ou classe de base.
-      Mais cette politique nécessite que chaque interface ou classe de base définisse entièrement dans sa Javadoc les critères ou calculs
-      que doivent employer les méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les implémentations.
-      Cette approche est choisie notamment par <code>java.util.Collection</code> et ses interfaces filles.
-      La transposition de cette approche aux centaines d’interfaces de GeoAPI serait toutefois une entreprise ardue,
-      qui risquerait d’être assez peu suivie par les diverses implémentations.
-      En outre, elle se fait au détriment de la possibilité de prendre en compte des attributs supplémentaires dans les interfaces filles
-      si cette possibilité n’a pas été spécifiée dans l’interface parente.
-      Cette contrainte découle des points suivants du contrat des méthodes <code>equals(Object)</code> et <code>hashCode()</code>:
-    </p>
-    <ul>
-      <li><code>A.equals(B)</code> implique <code>B.equals(A)</code> (symétrie);</li>
-      <li><code>A.equals(B)</code> et <code>B.equals(C)</code> implique <code>A.equals(C)</code> (transitivité);</li>
-      <li><code>A.equals(B)</code> implique <code>A.hashCode() == B.hashCode()</code>.</li>
-    </ul>
-    <p>
-      Par exemple ces trois contraintes sont violées si <var>A</var> (et éventuellement <var>C</var>)
-      peuvent contenir des attributs que <var>B</var> ignore.
-      Pour contourner cette difficulté, une approche alternative consiste à exiger que les objets comparés par la méthode
-      <code>Object.equals(Object)</code> soient exactement de la même classe, c’est-à-dire que <code>A.getClass() == B.getClass()</code>.
-      Cette approche est parfois considérée contraire aux principes de la programmation orientée objets.
-      Dans la pratique, pour des applications relativement complexes, l’importance accordée à ces principes dépend du contexte dans lequel les objets sont comparés:
-      si les objets sont ajoutés à un <code>HashSet</code> ou utilisés comme clés dans un <code>HashMap</code>,
-      alors nous avons besoin d’un strict respect du contrat de <code>equals(Object)</code> et <code>hashCode()</code>.
-      Mais si le développeur compare les objets lui-même, par exemple pour vérifier si des informations qui l’intéresse ont changées,
-      alors les contraintes de symétrie, transitivité ou de cohérence avec les valeurs de hachages peuvent ne pas être pertinentes pour lui.
-      Des comparaisons plus permissives peuvent être souhaitables, allant parfois jusqu’à tolérer de légers écarts dans les valeurs numériques.
-    </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>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>
-      <li><p>
-        <b><code class="SIS">STRICT</code></b> — Les objets comparés doivent être de la même classe
-        et tous leurs attributs strictement égaux, y compris d’éventuels attributs publics propres à l’implémentation.
-      </p></li>
-      <li><p>
-        <b><code class="SIS">BY_CONTRACT</code></b> — Les objets comparés doivent implémenter la même interface de GeoAPI (ou tout autre standard),
-        mais n’ont pas besoin d’être de la même classe d’implémentation. Seuls les attributs définis dans l’interface sont comparés;
-        tout autres attributs propres à l’implémentation — même s’ils sont publics — sont ignorés.
-      </p></li>
-      <li><p>
-        <b><code class="SIS">IGNORE_METADATA</code></b> — Comme <code class="SIS">BY_CONTRACT</code>,
-        mais ne compare que les attributs qui influencent les opérations (calculs numériques ou autre) effectuées par l’objet.
-        Par exemple dans un référentiel géodésique, la longitude (par rapport à Greenwich) du méridien d’origine sera pris en compte
-        alors que le nom de ce méridien sera ignoré.
-      </p></li>
-      <li><p>
-        <b><code class="SIS">APPROXIMATIVE</code></b> — Comme <code class="SIS">IGNORE_METADATA</code>,
-        mais tolère de légères différences dans les valeurs numériques.
-      </p></li>
-    </ul>
-    <p>
-      Le mode par défaut, utilisé par les toutes les méthodes <code>equals(Object)</code> de <abbr>SIS</abbr>,
-      est <code class="SIS">STRICT</code>. Ce mode est choisi pour une utilisation sécuritaire — notamment avec <code>HashMap</code> —
-      sans nécessiter de définitions rigoureuses des méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les interfaces.
-      Avec ce mode, l’ordre des objets (<code>A.equals(B)</code> ou <code>B.equals(A)</code>) n’a pas d’importance.
-      C’est toutefois le seul mode à offrir cette garantie.
-      Dans l’expression <code>A.equals(B)</code>, le mode <code class="SIS">BY_CONTRACT</code>
-      (et donc par extension tous les autres modes qui en dépendent) ne comparera que les propriétés connues de <code>A</code>,
-      sans se soucier de savoir si <code>B</code> en connaît davantage.
-    </p>
-
-
-
-    <h2 id="ObjectConverters">Object converters</h2>
-    <p>
-      Il est parfois nécessaire de convertir une instance d’un type source <code>&lt;S&gt;</code> vers un type destination <code>&lt;T&gt;</code>
-      alors que ces types ne sont pas connus au moment de la compilation.
-      Divers projets (Apache Common Convert, Spring, <i>etc.</i>)
-      ont créé leur propres interfaces pour effectuer des conversions d’objets entre des types connus seulement au moment de l’exécution.
-      Les détails varient, mais ces interfaces ressemblent typiquement à l’interface suivante:
-    </p>
-    <pre>interface ObjectConverter&lt;S,T&gt; {   // Certains projets utilisent seulement "Converter" comme nom d’interface.
+    <section>
+      <header>
+        <h1 id="Utilities">Classes et méthodes utilitaires</h1>
+      </header>
+      <p>
+        Ce chapitre décrit des aspects de Apache <abbr>SIS</abbr> qui s’appliquent à l’ensemble de la bibliothèque.
+        La plupart de ces utilitaires ne sont pas spécifiques aux systèmes d’information spatiales.
+      </p>
+
+      <h2 id="ComparisonMode">Modes de comparaisons des objets</h2>
+      <p>
+        Il existe différentes opinions sur la façon d’implémenter la méthode <code>Object.equals(Object)</code> du Java standard.
+        Selon certains, il doit être possible de comparer différentes implémentations d’une même interface ou classe de base.
+        Mais cette politique nécessite que chaque interface ou classe de base définisse entièrement dans sa Javadoc les critères ou calculs
+        que doivent employer les méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les implémentations.
+        Cette approche est choisie notamment par <code>java.util.Collection</code> et ses interfaces filles.
+        La transposition de cette approche aux centaines d’interfaces de GeoAPI serait toutefois une entreprise ardue,
+        qui risquerait d’être assez peu suivie par les diverses implémentations.
+        En outre, elle se fait au détriment de la possibilité de prendre en compte des attributs supplémentaires dans les interfaces filles
+        si cette possibilité n’a pas été spécifiée dans l’interface parente.
+        Cette contrainte découle des points suivants du contrat des méthodes <code>equals(Object)</code> et <code>hashCode()</code>:
+      </p>
+      <ul>
+        <li><code>A.equals(B)</code> implique <code>B.equals(A)</code> (symétrie);</li>
+        <li><code>A.equals(B)</code> et <code>B.equals(C)</code> implique <code>A.equals(C)</code> (transitivité);</li>
+        <li><code>A.equals(B)</code> implique <code>A.hashCode() == B.hashCode()</code>.</li>
+      </ul>
+      <p>
+        Par exemple ces trois contraintes sont violées si <var>A</var> (et éventuellement <var>C</var>)
+        peuvent contenir des attributs que <var>B</var> ignore.
+        Pour contourner cette difficulté, une approche alternative consiste à exiger que les objets comparés par la méthode
+        <code>Object.equals(Object)</code> soient exactement de la même classe, c’est-à-dire que <code>A.getClass() == B.getClass()</code>.
+        Cette approche est parfois considérée contraire aux principes de la programmation orientée objets.
+        Dans la pratique, pour des applications relativement complexes, l’importance accordée à ces principes dépend du contexte dans lequel les objets sont comparés:
+        si les objets sont ajoutés à un <code>HashSet</code> ou utilisés comme clés dans un <code>HashMap</code>,
+        alors nous avons besoin d’un strict respect du contrat de <code>equals(Object)</code> et <code>hashCode()</code>.
+        Mais si le développeur compare les objets lui-même, par exemple pour vérifier si des informations qui l’intéresse ont changées,
+        alors les contraintes de symétrie, transitivité ou de cohérence avec les valeurs de hachages peuvent ne pas être pertinentes pour lui.
+        Des comparaisons plus permissives peuvent être souhaitables, allant parfois jusqu’à tolérer de légers écarts dans les valeurs numériques.
+      </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>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>
+        <li><p>
+          <b><code class="SIS">STRICT</code></b> — Les objets comparés doivent être de la même classe
+          et tous leurs attributs strictement égaux, y compris d’éventuels attributs publics propres à l’implémentation.
+        </p></li>
+        <li><p>
+          <b><code class="SIS">BY_CONTRACT</code></b> — Les objets comparés doivent implémenter la même interface de GeoAPI (ou tout autre standard),
+          mais n’ont pas besoin d’être de la même classe d’implémentation. Seuls les attributs définis dans l’interface sont comparés;
+          tout autres attributs propres à l’implémentation — même s’ils sont publics — sont ignorés.
+        </p></li>
+        <li><p>
+          <b><code class="SIS">IGNORE_METADATA</code></b> — Comme <code class="SIS">BY_CONTRACT</code>,
+          mais ne compare que les attributs qui influencent les opérations (calculs numériques ou autre) effectuées par l’objet.
+          Par exemple dans un référentiel géodésique, la longitude (par rapport à Greenwich) du méridien d’origine sera pris en compte
+          alors que le nom de ce méridien sera ignoré.
+        </p></li>
+        <li><p>
+          <b><code class="SIS">APPROXIMATIVE</code></b> — Comme <code class="SIS">IGNORE_METADATA</code>,
+          mais tolère de légères différences dans les valeurs numériques.
+        </p></li>
+      </ul>
+      <p>
+        Le mode par défaut, utilisé par les toutes les méthodes <code>equals(Object)</code> de <abbr>SIS</abbr>,
+        est <code class="SIS">STRICT</code>. Ce mode est choisi pour une utilisation sécuritaire — notamment avec <code>HashMap</code> —
+        sans nécessiter de définitions rigoureuses des méthodes <code>equals(Object)</code> et <code>hashCode()</code> dans toutes les interfaces.
+        Avec ce mode, l’ordre des objets (<code>A.equals(B)</code> ou <code>B.equals(A)</code>) n’a pas d’importance.
+        C’est toutefois le seul mode à offrir cette garantie.
+        Dans l’expression <code>A.equals(B)</code>, le mode <code class="SIS">BY_CONTRACT</code>
+        (et donc par extension tous les autres modes qui en dépendent) ne comparera que les propriétés connues de <code>A</code>,
+        sans se soucier de savoir si <code>B</code> en connaît davantage.
+      </p>
+
+
+
+      <h2 id="ObjectConverters">Object converters</h2>
+      <p>
+        Il est parfois nécessaire de convertir une instance d’un type source <code>&lt;S&gt;</code> vers un type destination <code>&lt;T&gt;</code>
+        alors que ces types ne sont pas connus au moment de la compilation.
+        Divers projets (Apache Common Convert, Spring, <i>etc.</i>)
+        ont créé leur propres interfaces pour effectuer des conversions d’objets entre des types connus seulement au moment de l’exécution.
+        Les détails varient, mais ces interfaces ressemblent typiquement à l’interface suivante:
+      </p>
+
+<pre>interface ObjectConverter&lt;S,T&gt; {   // Certains projets utilisent seulement "Converter" comme nom d’interface.
     T apply(S object);             // Un autre nom de méthode souvent utilisé par les autres projets est "convert".
 }</pre>
-    <p>
-      Comme d’autres projets, Apache <abbr>SIS</abbr> définit sa propre interface <code>ObjectConverter</code>.
-      La principale différence entre l’interface de <abbr>SIS</abbr> est celle que l’on retrouve dans d’autres projets
-      est que <abbr>SIS</abbr> fournit des informations à propos de certaines propriétés mathématiques des convertisseurs.
-      Un convertisseur de Apache <abbr>SIS</abbr> peut avoir aucune, une ou plusieurs des propriétés suivantes:
-    </p>
-    <dl>
-      <dt><dfn>Injective</dfn></dt>
-      <dd>Une fonction est injective si aucune paire de valeurs de <var>S</var> ne peut produire la même valeur de <var>T</var>.
-        <div class="example"><p><b>Exemple:</b>
-          la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
-          est une fonction <cite>injective</cite> car si deux valeurs de type <code>Integer</code> ne sont pas égales,
-          alors il est garanti que leurs conversions produiront différentes valeurs de <code>String</code>.
-          En revanche la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
-          n’est <strong>pas</strong> une fonction injective
-          parce que plusieurs valeurs distinctes de type <code>String</code> peuvent être converties vers la même valeur de type <code>Integer</code>.
-          Par exemple les conversions des chaînes de caractères "42", "+42" et "0042" donnent toutes la même valeur entière 42.
-        </p></div>
-      </dd>
-
-      <dt><dfn>Surjective</dfn></dt>
-      <dd>Une fonction est surjective si chaque valeur de <var>T</var> peut être produite à partir d’au moins une valeur de <var>S</var>.
-        <div class="example"><p><b>Exemple:</b>
-          la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
-          est une fonction <cite>surjective</cite> car chaque valeur de type <code>Integer</code> peut être produite
-          à partir d’un moins une valeur de <code>String</code>.
-          En revanche la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
-          n’est <strong>pas</strong> une fonction surjective parce qu’elle ne peut pas produire toutes les valeurs possibles de type <code>String</code>.
-          Par exemple il n’y a aucun moyen de produire la valeur "ABC" avec la méthode <code>Integer.toString()</code>.
-        </p></div>
-      </dd>
-
-      <dt><dfn>Bijective</dfn></dt>
-      <dd>Une fonction est bijective s’il y a une relation de un-à-un entre les valeurs de <var>S</var> et de <var>T</var>.
-        <div class="example"><p><b>Note:</b>
-          la propriété <cite>bijective</cite> est définie ici pour des raisons de clarté,
-          mais en fait n’a pas d’item explicite dans l’énumération <code>FunctionProperty</code> de Apache <abbr>SIS</abbr>.
-          Ce n’est pas nécessaire puisqu’une fonction qui est à la fois <cite>injective</cite> et <cite>surjective</cite>
-          est nécessairement bijective.
-        </p></div>
-      </dd>
-
-      <dt><dfn>Préservant l’ordre</dfn></dt>
-      <dd>Une fonction préserve l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> croissantes.
-        <div class="example"><p><b>Exemple:</b>
-          la conversion du type <code>Integer</code> vers <code>Long</code> préserve l’ordre naturel des éléments.
-          Toutefois la conversion du type <code>Integer</code> vers <code>String</code> ne préserve <strong>pas</strong> l’ordre naturel,
-          parce que des séquences des nombres entiers croissants ont un ordre différents
-          lorsque les chaînes de caractères sont classées par ordre lexicographique.
-          Par exemple 1, 2, 10 devient "1", "10", "2".
-        </p></div>
-      </dd>
-
-      <dt><dfn>Renversant l’ordre</dfn></dt>
-      <dd>Une fonction renverse l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> décroissantes.
-        <div class="example"><p><b>Exemple:</b>
-          une conversion qui inverse le signe des nombres.
-        </p></div>
-      </dd>
-    </dl>
-    <p>
-      Ces informations peuvent sembler inutiles lorsque l’on convertit des valeurs sans tenir compte du contexte où elles apparaissent.
-      Mais lorsque la valeur à convertir fait parti d’un objet plus gros, alors ces informations peuvent impacter la façon dont la valeur convertie sera utilisée.
-      Par exemple la conversion d’une plage de valeurs représentée par [<var>min</var> … <var>max</var>] est directe lorsque la fonction de conversion préserve l’ordre.
-      Mais si la fonction de conversion renverse l’ordre, alors les valeurs minimale et maximale doivent être interchangées.
-      Par exemple si la fonction de conversion inverse le signe des valeurs, alors la plage convertie sera [-<var>max</var> … -<var>min</var>].
-      Si la fonction de conversion ne préserve ni ne renverse l’ordre, alors la plage de valeurs ne peut pas être convertie du tout
-      (parce qu’elle ne contiendrait plus le même ensemble de valeurs) même si les valeurs individuelles auraient pu être converties.
-    </p>
-
-
-
-    <h2 id="Internationalization">Internationalisation</h2>
-    <p>
-      Dans une architecture où un programme exécuté sur un serveur fournit ses données à plusieurs clients,
-      les conventions locales du serveur ne sont pas nécessairement les mêmes que celles des clients.
-      Les conventions peuvent différer par la langue, mais aussi par la façon d’écrire les valeurs numériques
-      (même entre deux pays parlant la même langue) ainsi que par le fuseau horaire.
-      Pour produire des messages conformes aux conventions du client, <abbr>SIS</abbr> emploie
-      deux approches qui diffèrent par leur niveau de granularité: au niveau des messages eux-mêmes,
-      ou au niveau des objets produisant les messages. L’approche utilisée détermine aussi s’il est
-      possible de partager une même instance d’un objet pour toutes les langues.
-    </p>
-
-    <h3 id="LocalizedString">Chaînes de caractères distinctes pour chaque conventions locales</h3>
-    <p>
-      Certaines classes ne sont conçues que pour fonctionner selon une convention locale à la fois.
-      C’est évidemment le cas des implémentations standards de <code>java.text.Format</code>,
-      puisqu’elles sont entièrement dédiées au travail d’internationalisation.
-      Mais c’est aussi le cas de d’autres classes moins évidentes comme
-      <code>javax.imageio.ImageReader</code> et <code>ImageWriter</code>.
-      Lorsque une de ces classes est implémentée par <abbr>SIS</abbr>,
-      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>
-      Une autre classe qui fournit différentes méthodes pour différentes langues est <code>java.lang.Throwable</code>.
-      L’<abbr>API</abbr> standard du Java définie deux méthodes pour obtenir un message d’erreur:
-      <code>getMessage()</code> et <code>getLocalizedMessage()</code>.
-      Habituellement, ces deux méthodes retournent la même chaîne de caractères.
-      Toutefois certaines exceptions lancées par Apache <abbr>SIS</abbr> peuvent utiliser différentes langues.
-      La politique que <abbr>SIS</abbr> tente d’appliquer autant que possible est:
-    </p>
-    <ul>
-      <li><code>getMessage()</code> retourne le message dans la langue par défaut de la <abbr title="Java Virtual Machine">JVM</abbr>.
-          Dans une architecture client-serveur, c’est souvent la langue du système hébergeant le serveur.
-          C’est la méthode recommandée pour enregistrer des messages dans le journal des événements,
-          à l’intention des administrateurs systèmes.</li>
-      <li><code>getLocalizedMessage()</code> retourne le message dans une langue qui dépend du contexte dans lequel l’exception s’est produite.
-          C’est souvent la langue qui a été configurée pour une instance particulière de <code>Format</code> ou <code class="SIS">DataStore</code>,
-          que l’on peut présumer être la langue du client se connectant au serveur.
-          C’est la méthode recommandée pour afficher un message dans une fenêtre sur le poste de l’utilisateur.</li>
-    </ul>
-
-    <div class="example"><p><b>Exemple:</b>
-      Si une erreur s’est produite alors qu’un client japonais s’est connecté à un serveur européen,
-      le message fournit par <code>getLocalizedMessage()</code> pourra être envoyé à l’utilisateur au Japon
-      alors que le message fournit par <code>getMessage()</code> pourra être enregistré dans le journal des événements du serveur.
-      Ainsi, l’administrateur système pourra plus facilement analyser l’erreur même s’il ne connaît pas la langue du client.
-    </p></div>
-    <p>
-      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>
-
-
-
-    <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>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
-      indépendamment des conventions locales.
-    </p>
-    <div class="example"><p><b>Exemple:</b>
-      Il existe dans <abbr>SIS</abbr> une seule instance de type
-      <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>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>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>
-
-
-
-    <h3 id="Locale.ROOT">Convention <code>Locale.ROOT</code></h3>
-    <p>
-      Toutes les méthodes <abbr>SIS</abbr> recevant ou retournant une valeur de type <code>Locale</code>
-      acceptent la valeur <code>Locale.ROOT</code>. Cette valeur est interprétée comme signifiant de ne pas localiser le texte.
-      La notion de <cite>texte non-localisé</cite> est un peu fausse, puisqu’il faut bien choisir une convention de format.
-      Mais cette convention, bien que très proche de l’anglais, sera généralement légèrement différente.
-      Par exemple:
-    </p>
-    <ul>
-      <li>
-        Les identifiants sont écrits tels qu’ils apparaissent dans les diagrammes <abbr>UML</abbr>,
-        par exemple <cite>blurredImage</cite> au lieu de <cite>Blurred image</cite>.
-      </li>
-      <li>
-        Les dates sont écrites selon le format <abbr>ISO</abbr> 8601,
-        qui ne correspond pas aux conventions anglaises.
-      </li>
-      <li>
-        Les nombres sont écrits à l’aide de leurs méthodes <code>toString()</code> plutôt qu’à l’aide d’un <code>java.text.NumberFormat</code>.
-        Il en résulte des différences dans le nombre de chiffres significatifs, l’utilisation de la notation exponentielle et l’absence de séparateur des milliers.
-      </li>
-    </ul>
-
-
-
-    <h3 id="UnicodePoint">Traitement des caractères</h3>
-    <p>
-      Les chaînes de caractères en Java utilisent l’encodage UTF-16. Il existe une correspondance directe
-      entre les valeurs de type <code>char</code> et la très grande majorité des caractères, ce
-      qui facilite l’utilisation des chaînes lorsque ces caractères suffisent.
-      Mais certains caractères Unicode ne sont pas représentables par un seul <code>char</code>.
-      Ces <i>caractères supplémentaires</i> comprennent certains idéogrammes,
-      mais aussi des symboles routiers et géographiques dans la plage 1F680 à 1F700.
-      Le support de ces caractères supplémentaires nécessite des itérations un peu plus complexes
-      que le cas classique où l’on supposait une correspondance directe.
-      Ainsi, au lieu de la boucle de gauche ci-dessous, les applications internationales devraient
-      généralement utiliser la boucle de droite:
-    </p>
-
-    <table class="hidden">
-      <tr>
-        <th>Boucle à éviter</th>
-        <th>Boucle recommandée</th>
-        <th>Exemples de caractères supplémentaires</th>
-      </tr>
-      <tr>
-        <td>
+
+      <p>
+        Comme d’autres projets, Apache <abbr>SIS</abbr> définit sa propre interface <code>ObjectConverter</code>.
+        La principale différence entre l’interface de <abbr>SIS</abbr> est celle que l’on retrouve dans d’autres projets
+        est que <abbr>SIS</abbr> fournit des informations à propos de certaines propriétés mathématiques des convertisseurs.
+        Un convertisseur de Apache <abbr>SIS</abbr> peut avoir aucune, une ou plusieurs des propriétés suivantes:
+      </p>
+      <dl>
+        <dt><dfn>Injective</dfn></dt>
+        <dd>Une fonction est injective si aucune paire de valeurs de <var>S</var> ne peut produire la même valeur de <var>T</var>.
+          <div class="example"><p><b>Exemple:</b>
+            la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
+            est une fonction <cite>injective</cite> car si deux valeurs de type <code>Integer</code> ne sont pas égales,
+            alors il est garanti que leurs conversions produiront différentes valeurs de <code>String</code>.
+            En revanche la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
+            n’est <strong>pas</strong> une fonction injective
+            parce que plusieurs valeurs distinctes de type <code>String</code> peuvent être converties vers la même valeur de type <code>Integer</code>.
+            Par exemple les conversions des chaînes de caractères "42", "+42" et "0042" donnent toutes la même valeur entière 42.
+          </p></div>
+        </dd>
+
+        <dt><dfn>Surjective</dfn></dt>
+        <dd>Une fonction est surjective si chaque valeur de <var>T</var> peut être produite à partir d’au moins une valeur de <var>S</var>.
+          <div class="example"><p><b>Exemple:</b>
+            la conversion <code>String</code> → <code>Integer</code> effectuée par <code>Integer.valueOf(String)</code>
+            est une fonction <cite>surjective</cite> car chaque valeur de type <code>Integer</code> peut être produite
+            à partir d’un moins une valeur de <code>String</code>.
+            En revanche la conversion <code>Integer</code> → <code>String</code> effectuée par <code>Integer.toString()</code>
+            n’est <strong>pas</strong> une fonction surjective parce qu’elle ne peut pas produire toutes les valeurs possibles de type <code>String</code>.
+            Par exemple il n’y a aucun moyen de produire la valeur "ABC" avec la méthode <code>Integer.toString()</code>.
+          </p></div>
+        </dd>
+
+        <dt><dfn>Bijective</dfn></dt>
+        <dd>Une fonction est bijective s’il y a une relation de un-à-un entre les valeurs de <var>S</var> et de <var>T</var>.
+          <div class="example"><p><b>Note:</b>
+            la propriété <cite>bijective</cite> est définie ici pour des raisons de clarté,
+            mais en fait n’a pas d’item explicite dans l’énumération <code>FunctionProperty</code> de Apache <abbr>SIS</abbr>.
+            Ce n’est pas nécessaire puisqu’une fonction qui est à la fois <cite>injective</cite> et <cite>surjective</cite>
+            est nécessairement bijective.
+          </p></div>
+        </dd>
+
+        <dt><dfn>Préservant l’ordre</dfn></dt>
+        <dd>Une fonction préserve l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> croissantes.
+          <div class="example"><p><b>Exemple:</b>
+            la conversion du type <code>Integer</code> vers <code>Long</code> préserve l’ordre naturel des éléments.
+            Toutefois la conversion du type <code>Integer</code> vers <code>String</code> ne préserve <strong>pas</strong> l’ordre naturel,
+            parce que des séquences des nombres entiers croissants ont un ordre différents
+            lorsque les chaînes de caractères sont classées par ordre lexicographique.
+            Par exemple 1, 2, 10 devient "1", "10", "2".
+          </p></div>
+        </dd>
+
+        <dt><dfn>Renversant l’ordre</dfn></dt>
+        <dd>Une fonction renverse l’ordre si toute séquence de valeurs <var>S</var> croissantes correspond à une séquence de valeurs <var>T</var> décroissantes.
+          <div class="example"><p><b>Exemple:</b>
+            une conversion qui inverse le signe des nombres.
+          </p></div>
+        </dd>
+      </dl>
+      <p>
+        Ces informations peuvent sembler inutiles lorsque l’on convertit des valeurs sans tenir compte du contexte où elles apparaissent.
+        Mais lorsque la valeur à convertir fait parti d’un objet plus gros, alors ces informations peuvent impacter la façon dont la valeur convertie sera utilisée.
+        Par exemple la conversion d’une plage de valeurs représentée par [<var>min</var> … <var>max</var>] est directe lorsque la fonction de conversion préserve l’ordre.
+        Mais si la fonction de conversion renverse l’ordre, alors les valeurs minimale et maximale doivent être interchangées.
+        Par exemple si la fonction de conversion inverse le signe des valeurs, alors la plage convertie sera [-<var>max</var> … -<var>min</var>].
+        Si la fonction de conversion ne préserve ni ne renverse l’ordre, alors la plage de valeurs ne peut pas être convertie du tout
+        (parce qu’elle ne contiendrait plus le même ensemble de valeurs) même si les valeurs individuelles auraient pu être converties.
+      </p>
+
+
+
+      <h2 id="Internationalization">Internationalisation</h2>
+      <p>
+        Dans une architecture où un programme exécuté sur un serveur fournit ses données à plusieurs clients,
+        les conventions locales du serveur ne sont pas nécessairement les mêmes que celles des clients.
+        Les conventions peuvent différer par la langue, mais aussi par la façon d’écrire les valeurs numériques
+        (même entre deux pays parlant la même langue) ainsi que par le fuseau horaire.
+        Pour produire des messages conformes aux conventions du client, <abbr>SIS</abbr> emploie
+        deux approches qui diffèrent par leur niveau de granularité: au niveau des messages eux-mêmes,
+        ou au niveau des objets produisant les messages. L’approche utilisée détermine aussi s’il est
+        possible de partager une même instance d’un objet pour toutes les langues.
+      </p>
+
+      <h3 id="LocalizedString">Chaînes de caractères distinctes pour chaque conventions locales</h3>
+      <p>
+        Certaines classes ne sont conçues que pour fonctionner selon une convention locale à la fois.
+        C’est évidemment le cas des implémentations standards de <code>java.text.Format</code>,
+        puisqu’elles sont entièrement dédiées au travail d’internationalisation.
+        Mais c’est aussi le cas de d’autres classes moins évidentes comme
+        <code>javax.imageio.ImageReader</code> et <code>ImageWriter</code>.
+        Lorsque une de ces classes est implémentée par <abbr>SIS</abbr>,
+        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>
+        Une autre classe qui fournit différentes méthodes pour différentes langues est <code>java.lang.Throwable</code>.
+        L’<abbr>API</abbr> standard du Java définie deux méthodes pour obtenir un message d’erreur:
+        <code>getMessage()</code> et <code>getLocalizedMessage()</code>.
+        Habituellement, ces deux méthodes retournent la même chaîne de caractères.
+        Toutefois certaines exceptions lancées par Apache <abbr>SIS</abbr> peuvent utiliser différentes langues.
+        La politique que <abbr>SIS</abbr> tente d’appliquer autant que possible est:
+      </p>
+      <ul>
+        <li><code>getMessage()</code> retourne le message dans la langue par défaut de la <abbr title="Java Virtual Machine">JVM</abbr>.
+            Dans une architecture client-serveur, c’est souvent la langue du système hébergeant le serveur.
+            C’est la méthode recommandée pour enregistrer des messages dans le journal des événements,
+            à l’intention des administrateurs systèmes.</li>
+        <li><code>getLocalizedMessage()</code> retourne le message dans une langue qui dépend du contexte dans lequel l’exception s’est produite.
+            C’est souvent la langue qui a été configurée pour une instance particulière de <code>Format</code> ou <code class="SIS">DataStore</code>,
+            que l’on peut présumer être la langue du client se connectant au serveur.
+            C’est la méthode recommandée pour afficher un message dans une fenêtre sur le poste de l’utilisateur.</li>
+      </ul>
+
+      <div class="example"><p><b>Exemple:</b>
+        Si une erreur s’est produite alors qu’un client japonais s’est connecté à un serveur européen,
+        le message fournit par <code>getLocalizedMessage()</code> pourra être envoyé à l’utilisateur au Japon
+        alors que le message fournit par <code>getMessage()</code> pourra être enregistré dans le journal des événements du serveur.
+        Ainsi, l’administrateur système pourra plus facilement analyser l’erreur même s’il ne connaît pas la langue du client.
+      </p></div>
+      <p>
+        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>
+
+
+
+      <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>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
+        indépendamment des conventions locales.
+      </p>
+      <div class="example"><p><b>Exemple:</b>
+        Il existe dans <abbr>SIS</abbr> une seule instance de type
+        <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>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>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>
+
+
+
+      <h3 id="Locale.ROOT">Convention <code>Locale.ROOT</code></h3>
+      <p>
+        Toutes les méthodes <abbr>SIS</abbr> recevant ou retournant une valeur de type <code>Locale</code>
+        acceptent la valeur <code>Locale.ROOT</code>. Cette valeur est interprétée comme signifiant de ne pas localiser le texte.
+        La notion de <cite>texte non-localisé</cite> est un peu fausse, puisqu’il faut bien choisir une convention de format.
+        Mais cette convention, bien que très proche de l’anglais, sera généralement légèrement différente.
+        Par exemple:
+      </p>
+      <ul>
+        <li>
+          Les identifiants sont écrits tels qu’ils apparaissent dans les diagrammes <abbr>UML</abbr>,
+          par exemple <cite>blurredImage</cite> au lieu de <cite>Blurred image</cite>.
+        </li>
+        <li>
+          Les dates sont écrites selon le format <abbr>ISO</abbr> 8601,
+          qui ne correspond pas aux conventions anglaises.
+        </li>
+        <li>
+          Les nombres sont écrits à l’aide de leurs méthodes <code>toString()</code> plutôt qu’à l’aide d’un <code>java.text.NumberFormat</code>.
+          Il en résulte des différences dans le nombre de chiffres significatifs, l’utilisation de la notation exponentielle et l’absence de séparateur des milliers.
+        </li>
+      </ul>
+
+
+
+      <h3 id="UnicodePoint">Traitement des caractères</h3>
+      <p>
+        Les chaînes de caractères en Java utilisent l’encodage UTF-16. Il existe une correspondance directe
+        entre les valeurs de type <code>char</code> et la très grande majorité des caractères, ce
+        qui facilite l’utilisation des chaînes lorsque ces caractères suffisent.
+        Mais certains caractères Unicode ne sont pas représentables par un seul <code>char</code>.
+        Ces <i>caractères supplémentaires</i> comprennent certains idéogrammes,
+        mais aussi des symboles routiers et géographiques dans la plage 1F680 à 1F700.
+        Le support de ces caractères supplémentaires nécessite des itérations un peu plus complexes
+        que le cas classique où l’on supposait une correspondance directe.
+        Ainsi, au lieu de la boucle de gauche ci-dessous, les applications internationales devraient
+        généralement utiliser la boucle de droite:
+      </p>
+
+      <table class="hidden">
+        <tr>
+          <th>Boucle à éviter</th>
+          <th>Boucle recommandée</th>
+          <th>Exemples de caractères supplémentaires</th>
+        </tr>
+        <tr>
+          <td>
 <pre style="margin-top: 6pt">for (int i=0; i&lt;string.length(); i++) {
     char c = string.charAt(i);
     if (Character.isWhitespace(c)) {
         // Un espace blanc a été trouvé.
     }
 }</pre>
-        </td>
-        <td>
+
+          </td><td>
+
 <pre style="margin-top: 6pt">for (int i=0; i&lt;string.length();) {
     int c = string.codePointAt(i);
     if (Character.isWhitespace(c)) {
@@ -339,55 +343,56 @@
     }
     i += Character.charCount(c);
 }</pre>
-        </td>
-        <td>
-          <center>(l’affichage dépend des capacités du navigateur)</center>
-          <p style="font-size: 40px">&#x1F689; &#x1F6A5; &#x1F6A7; &#x1F6AB;
-            &#x1F6AF; &#x1F6B8; &#x1F6BA; &#x1F6B9; &#x1F6C4; &#x1F6AD;</p>
-        </td>
-      </tr>
-    </table>
-
-    <p>
-      <abbr>SIS</abbr> supporte les caractères supplémentaires en utilisant la boucle de droite lorsque nécessaire.
-      Mais la boucle de gauche reste occasionnellement utilisée lorsqu’il est connu que les caractères recherchés ne sont
-      pas des caractères supplémentaires, même si la chaîne dans laquelle on fait la recherche peut en contenir.
-    </p>
+
+          </td><td>
+            <center>(l’affichage dépend des capacités du navigateur)</center>
+            <p style="font-size: 40px">&#x1F689; &#x1F6A5; &#x1F6A7; &#x1F6AB;
+              &#x1F6AF; &#x1F6B8; &#x1F6BA; &#x1F6B9; &#x1F6C4; &#x1F6AD;</p>
+          </td>
+        </tr>
+      </table>
+
+      <p>
+        <abbr>SIS</abbr> supporte les caractères supplémentaires en utilisant la boucle de droite lorsque nécessaire.
+        Mais la boucle de gauche reste occasionnellement utilisée lorsqu’il est connu que les caractères recherchés ne sont
+        pas des caractères supplémentaires, même si la chaîne dans laquelle on fait la recherche peut en contenir.
+      </p>
 
 
 
-    <h4 id="Whitespaces">Interprétation des espaces blancs</h4>
-    <p>
-      Le Java standard fournit deux méthodes pour déterminer si un caractères est un espace blanc:
-      <code>Character.isWhitespace(…)</code> et <code>Character.isSpaceChar(…)</code>.
-      Ces deux méthodes diffèrent dans leurs interprétations des espaces insécables, des tabulations et des retours à la ligne.
-      La première méthode est conforme à l’interprétation couramment utilisée dans des langages telles que le Java, C/C++ et <abbr>XML</abbr>,
-      qui considère les tabulations et retours à la ligne comme des espaces blancs,
-      alors que les espaces insécables sont interprétés comme des caractères non-blanc.
-      La seconde méthode — strictement conforme à la définition Unicode — fait l’interprétation inverse.
-    </p>
-    <p>
-      <abbr>SIS</abbr> emploie ces deux méthodes dans des contextes différents.
-      <code>isWhitespace(…)</code> est utilisée pour <em>séparer</em> les éléments d’une liste (nombres, dates, mots, <i>etc.</i>),
-      tandis que <code>isSpaceChar(…)</code> est utilisée pour ignorer les espaces blancs <em>à l’intérieur</em> d’un seul élément.
-    </p>
-    <div class="example"><p><b>Exemple:</b>
-      Supposons une liste de nombres représentés selon les conventions françaises.
-      Chaque nombre peut contenir des <em>espace insécables</em> comme séparateurs des milliers,
-      tandis que les différents nombres de la liste peuvent être séparés par des espaces ordinaires, des tabulations ou des retours à la ligne.
-      Pendant l’analyse d’un nombre, on veut considérer les espaces insécables comme faisant partie du nombre,
-      alors qu’une tabulation ou un retour à la ligne indique très probablement une séparation entre ce nombre et le nombre suivant.
-      On utilisera donc <code>isSpaceChar(…)</code>.
-      Inversement, lors de la séparation des nombres de la liste, on veut considérer les tabulations et
-      les retours à la ligne comme des séparateurs mais pas les espaces insécables.
-      On utilisera donc <code>isWhitespace(…)</code>.
-      Le rôle des espaces ordinaires, qui pourraient s’appliquer aux deux cas, doit être décidé en amont.
-    </p></div>
-    <p>
-      Dans la pratique, cette distinction se traduit pas une utilisation de <code>isSpaceChar(…)</code>
-      dans les implémentations de <code>java.text.Format</code>,
-      et une utilisation de <code>isWhitespace(…)</code> dans pratiquement tout le reste
-      de la bibliothèque <abbr>SIS</abbr>.
-    </p>
+      <h4 id="Whitespaces">Interprétation des espaces blancs</h4>
+      <p>
+        Le Java standard fournit deux méthodes pour déterminer si un caractères est un espace blanc:
+        <code>Character.isWhitespace(…)</code> et <code>Character.isSpaceChar(…)</code>.
+        Ces deux méthodes diffèrent dans leurs interprétations des espaces insécables, des tabulations et des retours à la ligne.
+        La première méthode est conforme à l’interprétation couramment utilisée dans des langages telles que le Java, C/C++ et <abbr>XML</abbr>,
+        qui considère les tabulations et retours à la ligne comme des espaces blancs,
+        alors que les espaces insécables sont interprétés comme des caractères non-blanc.
+        La seconde méthode — strictement conforme à la définition Unicode — fait l’interprétation inverse.
+      </p>
+      <p>
+        <abbr>SIS</abbr> emploie ces deux méthodes dans des contextes différents.
+        <code>isWhitespace(…)</code> est utilisée pour <em>séparer</em> les éléments d’une liste (nombres, dates, mots, <i>etc.</i>),
+        tandis que <code>isSpaceChar(…)</code> est utilisée pour ignorer les espaces blancs <em>à l’intérieur</em> d’un seul élément.
+      </p>
+      <div class="example"><p><b>Exemple:</b>
+        Supposons une liste de nombres représentés selon les conventions françaises.
+        Chaque nombre peut contenir des <em>espace insécables</em> comme séparateurs des milliers,
+        tandis que les différents nombres de la liste peuvent être séparés par des espaces ordinaires, des tabulations ou des retours à la ligne.
+        Pendant l’analyse d’un nombre, on veut considérer les espaces insécables comme faisant partie du nombre,
+        alors qu’une tabulation ou un retour à la ligne indique très probablement une séparation entre ce nombre et le nombre suivant.
+        On utilisera donc <code>isSpaceChar(…)</code>.
+        Inversement, lors de la séparation des nombres de la liste, on veut considérer les tabulations et
+        les retours à la ligne comme des séparateurs mais pas les espaces insécables.
+        On utilisera donc <code>isWhitespace(…)</code>.
+        Le rôle des espaces ordinaires, qui pourraient s’appliquer aux deux cas, doit être décidé en amont.
+      </p></div>
+      <p>
+        Dans la pratique, cette distinction se traduit pas une utilisation de <code>isSpaceChar(…)</code>
+        dans les implémentations de <code>java.text.Format</code>,
+        et une utilisation de <code>isWhitespace(…)</code> dans pratiquement tout le reste
+        de la bibliothèque <abbr>SIS</abbr>.
+      </p>
+    </section>
   </body>
 </html>

Modified: sis/site/trunk/book/fr/xml.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/xml.html?rev=1794573&r1=1794572&r2=1794573&view=diff
==============================================================================
--- sis/site/trunk/book/fr/xml.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/xml.html [UTF-8] Tue May  9 13:09:58 2017
@@ -31,120 +31,121 @@
       Content below this point is copied in "../../content/book/fr/developer-guide.html"
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
-    <header>
-      <h1 id="XML-ISO">Représentation des objets en <abbr>XML</abbr></h1>
-    </header>
-    <p>
-      Les objets définis par les standards <abbr>OGC</abbr>/<abbr>ISO</abbr> doivent pouvoir être échangés sur internet
-      entre des machines distantes, utilisant des logiciels différents écrits dans des langages différents.
-      Quelques uns des formats les plus connus sont
-      le <abbr>WKT</abbr> (<i>Well-Known Text</i>) et
-      le <abbr>WKB</abbr> (<i>Well-Known Binary</i>).
-      Mais le format le plus exhaustif et souvent considéré comme la référence est le <abbr>XML</abbr>,
-      au point où la façon de représenter les objets <abbr>ISO</abbr> dans ce format fait parfois l’objet d’un standard international à part entière.
-      Ainsi, les classes de méta-données sont décrites dans le standard <abbr>ISO</abbr> 19115-1 (une spécification dite <i>abstraite</i>),
-      alors que la représentation de ces classes en <abbr>XML</abbr> est décrite par les standards <abbr>ISO</abbr> 19115-3 et 19139.
-    </p>
-    <p>
-      Les différents standards <abbr>OGC</abbr>/<abbr>ISO</abbr> n’emploient pas tous la même stratégie pour exprimer les objets en <abbr>XML</abbr>.
-      Le standard <abbr>ISO</abbr> 19115-3 en particulier emploie une approche plus verbeuse que les autres normes,
-      et fera l’objet d’une <a href="#XML-ISO-19115">section particulière</a>.
-      Mais la plupart des formats <abbr>XML</abbr> ont en commun de définir des types et des attributs supplémentaires
-      qui ne font pas partie des spécifications abstraites d’origines.
-      Ces attributs supplémentaires sont habituellement propres au <abbr>XML</abbr> et peuvent ne pas apparaître directement dans l’<abbr>API</abbr> de Apache <abbr>SIS</abbr>.
-      Certains de ces attributs, notamment <code class="OGC">id</code>, <code class="OGC">uuid</code> et <code>xlink:href</code>,
-      restent toutefois accessibles sous forme de paires clé-valeurs.
-    </p>
-    <p>
-      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>org.apache.sis.xml.Namespaces</code>.
-    </p>
-    <table>
-      <caption>Préfixes d’espaces de noms <abbr>XML</abbr> courants</caption>
-      <tr>
-        <th>Préfixe</th>
-        <th>Espace de nom</th>
-      </tr>
-      <tr>
-        <td><code>gco</code></td>
-        <td><code>http://www.isotc211.org/2005/gco</code></td>
-      </tr>
-      <tr>
-        <td><code>gfc</code></td>
-        <td><code>http://www.isotc211.org/2005/gfc</code></td>
-      </tr>
-      <tr>
-        <td><code>gmd</code></td>
-        <td><code>http://www.isotc211.org/2005/gmd</code></td>
-      </tr>
-      <tr>
-        <td><code>gmi</code></td>
-        <td><code>http://www.isotc211.org/2005/gmi</code></td>
-      </tr>
-      <tr>
-        <td><code>gmx</code></td>
-        <td><code>http://www.isotc211.org/2005/gmx</code></td>
-      </tr>
-      <tr>
-        <td><code>gml</code></td>
-        <td><code>http://www.opengis.net/gml/3.2</code></td>
-      </tr>
-      <tr>
-        <td><code>xlink</code></td>
-        <td><code>http://www.w3.org/1999/xlink</code></td>
-      </tr>
-    </table>
-
-    <aside>
-      <h2>Outils de lecture et d’écriture de documents <abbr>XML</abbr></h2>
-      <p>
-        Apache <abbr>SIS</abbr> emploie différentes bibliothèques pour lire et écrire différents type d’objets.
-        La bibliothèque utilisée dépend de la complexité de l’objet et des contraintes de performances.
-        Par exemple les annotations de <abbr title="Java Architecture for XML Binding">JAXB</abbr> ont l’avantage d’être proches du code,
-        ce qui facilite la maintenance de la correspondance entre le Java et le <abbr>XML</abbr>.
-        En revanche <abbr title="Simple API for XML">SAX</abbr> a l’avantage d’être performant.
-        De manière générale, Apache <abbr>SIS</abbr> emploie:
+    <section>
+      <header>
+        <h1 id="XML-ISO">Représentation des objets en <abbr>XML</abbr></h1>
+      </header>
+      <p>
+        Les objets définis par les standards <abbr>OGC</abbr>/<abbr>ISO</abbr> doivent pouvoir être échangés sur internet
+        entre des machines distantes, utilisant des logiciels différents écrits dans des langages différents.
+        Quelques uns des formats les plus connus sont
+        le <abbr>WKT</abbr> (<i>Well-Known Text</i>) et
+        le <abbr>WKB</abbr> (<i>Well-Known Binary</i>).
+        Mais le format le plus exhaustif et souvent considéré comme la référence est le <abbr>XML</abbr>,
+        au point où la façon de représenter les objets <abbr>ISO</abbr> dans ce format fait parfois l’objet d’un standard international à part entière.
+        Ainsi, les classes de méta-données sont décrites dans le standard <abbr>ISO</abbr> 19115-1 (une spécification dite <i>abstraite</i>),
+        alors que la représentation de ces classes en <abbr>XML</abbr> est décrite par les standards <abbr>ISO</abbr> 19115-3 et 19139.
       </p>
-      <ul>
-        <li>
-          <abbr>JAXB</abbr> pour les objets qui ne sont pas répétés très souvent dans le document
-          mais dont la structure est complexe, avec des arborescences profondes.
-          L’ensemble des méta-données <abbr>ISO</abbr> 19115-3 est un exemple typique.
-        </li>
-        <li>
-          <abbr>SAX</abbr> pour les objets relativement simples mais pouvant exister en très grand nombre.
-          L’ensemble des points dans une géométrie est un exemple typique.
-        </li>
-        <li>
-          <abbr title="Document Object Model">DOM</abbr> comme une alternative à <abbr>JAXB</abbr>
-          lorsque les éléments <abbr>XML</abbr> ne correspondent pas directement à des attributs Java.
-          Les <i>features</i> en sont un exemple, car leur structure est dynamique.
-        </li>
-      </ul>
-    </aside>
+      <p>
+        Les différents standards <abbr>OGC</abbr>/<abbr>ISO</abbr> n’emploient pas tous la même stratégie pour exprimer les objets en <abbr>XML</abbr>.
+        Le standard <abbr>ISO</abbr> 19115-3 en particulier emploie une approche plus verbeuse que les autres normes,
+        et fera l’objet d’une <a href="#XML-ISO-19115">section particulière</a>.
+        Mais la plupart des formats <abbr>XML</abbr> ont en commun de définir des types et des attributs supplémentaires
+        qui ne font pas partie des spécifications abstraites d’origines.
+        Ces attributs supplémentaires sont habituellement propres au <abbr>XML</abbr> et peuvent ne pas apparaître directement dans l’<abbr>API</abbr> de Apache <abbr>SIS</abbr>.
+        Certains de ces attributs, notamment <code class="OGC">id</code>, <code class="OGC">uuid</code> et <code>xlink:href</code>,
+        restent toutefois accessibles sous forme de paires clé-valeurs.
+      </p>
+      <p>
+        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>org.apache.sis.xml.Namespaces</code>.
+      </p>
+      <table>
+        <caption>Préfixes d’espaces de noms <abbr>XML</abbr> courants</caption>
+        <tr>
+          <th>Préfixe</th>
+          <th>Espace de nom</th>
+        </tr>
+        <tr>
+          <td><code>gco</code></td>
+          <td><code>http://www.isotc211.org/2005/gco</code></td>
+        </tr>
+        <tr>
+          <td><code>gfc</code></td>
+          <td><code>http://www.isotc211.org/2005/gfc</code></td>
+        </tr>
+        <tr>
+          <td><code>gmd</code></td>
+          <td><code>http://www.isotc211.org/2005/gmd</code></td>
+        </tr>
+        <tr>
+          <td><code>gmi</code></td>
+          <td><code>http://www.isotc211.org/2005/gmi</code></td>
+        </tr>
+        <tr>
+          <td><code>gmx</code></td>
+          <td><code>http://www.isotc211.org/2005/gmx</code></td>
+        </tr>
+        <tr>
+          <td><code>gml</code></td>
+          <td><code>http://www.opengis.net/gml/3.2</code></td>
+        </tr>
+        <tr>
+          <td><code>xlink</code></td>
+          <td><code>http://www.w3.org/1999/xlink</code></td>
+        </tr>
+      </table>
+
+      <aside>
+        <h2>Outils de lecture et d’écriture de documents <abbr>XML</abbr></h2>
+        <p>
+          Apache <abbr>SIS</abbr> emploie différentes bibliothèques pour lire et écrire différents type d’objets.
+          La bibliothèque utilisée dépend de la complexité de l’objet et des contraintes de performances.
+          Par exemple les annotations de <abbr title="Java Architecture for XML Binding">JAXB</abbr> ont l’avantage d’être proches du code,
+          ce qui facilite la maintenance de la correspondance entre le Java et le <abbr>XML</abbr>.
+          En revanche <abbr title="Simple API for XML">SAX</abbr> a l’avantage d’être performant.
+          De manière générale, Apache <abbr>SIS</abbr> emploie:
+        </p>
+        <ul>
+          <li>
+            <abbr>JAXB</abbr> pour les objets qui ne sont pas répétés très souvent dans le document
+            mais dont la structure est complexe, avec des arborescences profondes.
+            L’ensemble des méta-données <abbr>ISO</abbr> 19115-3 est un exemple typique.
+          </li>
+          <li>
+            <abbr>SAX</abbr> pour les objets relativement simples mais pouvant exister en très grand nombre.
+            L’ensemble des points dans une géométrie est un exemple typique.
+          </li>
+          <li>
+            <abbr title="Document Object Model">DOM</abbr> comme une alternative à <abbr>JAXB</abbr>
+            lorsque les éléments <abbr>XML</abbr> ne correspondent pas directement à des attributs Java.
+            Les <i>features</i> en sont un exemple, car leur structure est dynamique.
+          </li>
+        </ul>
+      </aside>
 
 
 
-    <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>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>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>CI_Citation</code>,
-      la valeur de la propriété <code class="OGC">citedResponsibleParty</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>
+      <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>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>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>CI_Citation</code>,
+        la valeur de la propriété <code class="OGC">citedResponsibleParty</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>
 
 <pre class="xml"><b>&lt;MD_Metadata&gt;</b>
   &lt;identificationInfo&gt;
@@ -176,78 +177,79 @@
   &lt;/identificationInfo&gt;
 <b>&lt;/MD_Metadata&gt;</b></pre>
 
-    <p>
-      L’exemple précédent, comme tous les documents conformes à <abbr>ISO</abbr> 19139,
-      est donc constitué d’une alternance systématique de deux types d’éléments <abbr>XML</abbr> imbriqués:
-    </p>
-    <ol>
-      <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>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>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>
-
-    <p>
-      Afin de réduire la complexité des bibliothèques, GeoAPI et Apache <abbr>SIS</abbr>
-      n’exposent publiquement qu’une vision unifiée de ces deux types d’éléments.
-      L’<abbr>API</abbr> public correspond essentiellement au deuxième groupe.
-      Toutefois, lors de l’écriture d’un document <abbr>XML</abbr>, des éléments du premier groupe doivent être temporairement recréés.
-      Les classes qui y correspondent sont définies dans des paquets internes de <abbr>SIS</abbr>.
-      Ces classes peuvent être ignorées, sauf si le développeur souhaite implémenter ses propres classes
-      dont les instances devront être lues et écrites par <abbr>JAXB</abbr>.
-    </p>
-
-    <aside>
-      <h3>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></h3>
-      <p>
-        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.
-        De manière opportuniste, <abbr>SIS</abbr> en fait à la fois des adaptateurs <abbr>JAXB</abbr>
-        et des objets enveloppants le “vrai” objet à lire ou écrire.
-        Cette utilisation double permet d’éviter d’avoir à doubler le nombre de classes
-        (déjà très élevé) présents dans les paquets internes.
-      </p>
-      <h4>Convention de nommage dans les schémas <abbr>XSD</abbr></h4>
-      <p>
-        Les schémas <abbr>XSD</abbr> de l’<abbr>OGC</abbr> définissent pour chaque élément du premier groupe
-        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>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>
-    </aside>
-
-
-    <h3 id="gco-id">Identification d’instances déjà définies</h3>
-    <p>
-      L’élément englobant peut contenir un attribut <code class="OGC">id</code> ou <code class="OGC">uuid</code>.
-      Si un de ces attributs est présent, l’élément englobé peut être complètement omis;
-      il sera remplacé au moment de la lecture par l’élément référencé par l’attribut.
-      Dans l’exemple suivant, la partie gauche définie un élément associé à l’identifiant “<code>mon_id</code>”,
-      alors que la partie droite référence cet élément:
-    </p>
-
-    <table class="hidden">
-      <tr>
-        <th>Définir un identifiant</th>
-        <th>Utiliser l’identifiant défini</th>
-      </tr>
-      <tr>
-        <td>
+      <p>
+        L’exemple précédent, comme tous les documents conformes à <abbr>ISO</abbr> 19139,
+        est donc constitué d’une alternance systématique de deux types d’éléments <abbr>XML</abbr> imbriqués:
+      </p>
+      <ol>
+        <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>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>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>
+
+      <p>
+        Afin de réduire la complexité des bibliothèques, GeoAPI et Apache <abbr>SIS</abbr>
+        n’exposent publiquement qu’une vision unifiée de ces deux types d’éléments.
+        L’<abbr>API</abbr> public correspond essentiellement au deuxième groupe.
+        Toutefois, lors de l’écriture d’un document <abbr>XML</abbr>, des éléments du premier groupe doivent être temporairement recréés.
+        Les classes qui y correspondent sont définies dans des paquets internes de <abbr>SIS</abbr>.
+        Ces classes peuvent être ignorées, sauf si le développeur souhaite implémenter ses propres classes
+        dont les instances devront être lues et écrites par <abbr>JAXB</abbr>.
+      </p>
+
+      <aside>
+        <h3>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></h3>
+        <p>
+          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.
+          De manière opportuniste, <abbr>SIS</abbr> en fait à la fois des adaptateurs <abbr>JAXB</abbr>
+          et des objets enveloppants le “vrai” objet à lire ou écrire.
+          Cette utilisation double permet d’éviter d’avoir à doubler le nombre de classes
+          (déjà très élevé) présents dans les paquets internes.
+        </p>
+        <h4>Convention de nommage dans les schémas <abbr>XSD</abbr></h4>
+        <p>
+          Les schémas <abbr>XSD</abbr> de l’<abbr>OGC</abbr> définissent pour chaque élément du premier groupe
+          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>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>
+      </aside>
+
+
+      <h3 id="gco-id">Identification d’instances déjà définies</h3>
+      <p>
+        L’élément englobant peut contenir un attribut <code class="OGC">id</code> ou <code class="OGC">uuid</code>.
+        Si un de ces attributs est présent, l’élément englobé peut être complètement omis;
+        il sera remplacé au moment de la lecture par l’élément référencé par l’attribut.
+        Dans l’exemple suivant, la partie gauche définie un élément associé à l’identifiant “<code>mon_id</code>”,
+        alors que la partie droite référence cet élément:
+      </p>
+
+      <table class="hidden">
+        <tr>
+          <th>Définir un identifiant</th>
+          <th>Utiliser l’identifiant défini</th>
+        </tr>
+        <tr>
+          <td>
+
 <pre class="xml" style="margin-top: 6pt">&lt;MD_MetaData&gt;
   &lt;identificationInfo&gt;
     &lt;MD_DataIdentification id="<b>mon_id</b>"&gt;
@@ -255,42 +257,44 @@
     &lt;/MD_DataIdentification&gt;
   &lt;/identificationInfo&gt;
 &lt;/MD_MetaData&gt;</pre>
-        </td>
-        <td>
+
+          </td><td>
+
 <pre class="xml" style="margin-top: 6pt">&lt;MD_MetaData&gt;
   &lt;identificationInfo xlink:href="<b>#mon_id</b>"/&gt;
 &lt;/MD_MetaData&gt;</pre>
-        </td>
-      </tr>
-    </table>
-
-    <p>
-      Le choix de l’attribut à utiliser dépend de la portée de l’élément référencé:
-    </p>
-    <ul>
-      <li>
-        <code class="OGC">id</code> n’est valide qu’à l’intérieur du document <abbr>XML</abbr>
-        qui définit l’objet ainsi référencé.
-      </li>
-      <li>
-        <code class="OGC">uuid</code> peut être valide à l’extérieur du document <abbr>XML</abbr>,
-        mais quelqu’un doit maintenir une base de données fournissant les objets pour chaque UUID donnés.
-      </li>
-      <li>
-        <code>xlink:href</code> peut faire référence à un autre document <abbr>XML</abbr> accessible sur internet.
-      </li>
-    </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>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>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>
+
+          </td>
+        </tr>
+      </table>
+
+      <p>
+        Le choix de l’attribut à utiliser dépend de la portée de l’élément référencé:
+      </p>
+      <ul>
+        <li>
+          <code class="OGC">id</code> n’est valide qu’à l’intérieur du document <abbr>XML</abbr>
+          qui définit l’objet ainsi référencé.
+        </li>
+        <li>
+          <code class="OGC">uuid</code> peut être valide à l’extérieur du document <abbr>XML</abbr>,
+          mais quelqu’un doit maintenir une base de données fournissant les objets pour chaque UUID donnés.
+        </li>
+        <li>
+          <code>xlink:href</code> peut faire référence à un autre document <abbr>XML</abbr> accessible sur internet.
+        </li>
+      </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>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>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 org.apache.sis.metadata.iso.DefaultMetadata;
 import org.apache.sis.xml.IdentifierSpace;
@@ -304,54 +308,54 @@ public class MyClass {
     }
 }</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>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>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>
+      <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>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>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>
 
 
 
-    <h3 id="nilReason">Représentation de valeurs manquantes</h3>
-    <p>
-      Lorsqu’une propriété n’est pas définie, la méthode correspondante de GeoAPI retourne généralement <code>null</code>.
-      Toutefois les choses se compliquent lorsque la propriété manquante est une valeur considérée comme obligatoire par le standard <abbr>ISO</abbr> 19115.
-      Le standard <abbr>ISO</abbr> 19139 autorise l’omission de propriétés obligatoires à la condition d’indiquer pourquoi la valeur est manquante.
-      Les raisons peuvent être que la propriété ne s’applique pas (<code class="OGC">inapplicable</code>),
-      que la valeur existe probablement mais n’est pas connue (<code class="OGC">unknown</code>),
-      que la valeur pourrait ne pas exister (<code class="OGC">missing</code>),
-      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>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>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>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>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>
-
-    <table class="hidden">
-      <tr>
-        <th>Information présente</th>
-        <th>Information absente</th>
-      </tr>
-      <tr>
-        <td>
+      <h3 id="nilReason">Représentation de valeurs manquantes</h3>
+      <p>
+        Lorsqu’une propriété n’est pas définie, la méthode correspondante de GeoAPI retourne généralement <code>null</code>.
+        Toutefois les choses se compliquent lorsque la propriété manquante est une valeur considérée comme obligatoire par le standard <abbr>ISO</abbr> 19115.
+        Le standard <abbr>ISO</abbr> 19139 autorise l’omission de propriétés obligatoires à la condition d’indiquer pourquoi la valeur est manquante.
+        Les raisons peuvent être que la propriété ne s’applique pas (<code class="OGC">inapplicable</code>),
+        que la valeur existe probablement mais n’est pas connue (<code class="OGC">unknown</code>),
+        que la valeur pourrait ne pas exister (<code class="OGC">missing</code>),
+        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>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>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>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>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>
+
+      <table class="hidden">
+        <tr>
+          <th>Information présente</th>
+          <th>Information absente</th>
+        </tr>
+        <tr>
+          <td>
 <pre class="xml" style="margin-top: 6pt">&lt;CI_Citation&gt;
   &lt;series&gt;
     &lt;CI_Series&gt;
@@ -359,13 +363,16 @@ public class MyClass {
     &lt;/CI_Series&gt;
   &lt;/series&gt;
 &lt;/CI_Citation&gt;</pre>
-        </td>
-        <td>
+
+          </td><td>
+
 <pre class="xml" style="margin-top: 6pt">&lt;CI_Citation&gt;
   &lt;series nilReason="unknown"/&gt;
 &lt;/CI_Citation&gt;</pre>
-        </td>
-      </tr>
-    </table>
+
+          </td>
+        </tr>
+      </table>
+    </section>
   </body>
 </html>



Mime
View raw message