sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1794656 [18/18] - in /sis/site/trunk/book: en/ en/annex/ en/coverage/ en/geometry/ en/introduction/ en/referencing/ en/utility/ en/xml/ fr/ fr/annex/ fr/coverage/ fr/geometry/ fr/introduction/ fr/referencing/ fr/utility/ fr/xml/
Date Tue, 09 May 2017 23:04:36 GMT
Copied: sis/site/trunk/book/fr/utility/ObjectConverters.html (from r1794573, sis/site/trunk/book/fr/utility.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/utility/ObjectConverters.html?p2=sis/site/trunk/book/fr/utility/ObjectConverters.html&p1=sis/site/trunk/book/fr/utility.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/utility.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/utility/ObjectConverters.html [UTF-8] Tue May  9 23:04:35 2017
@@ -22,96 +22,20 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
   <head>
-    <title>Classes et méthodes utilitaires</title>
+    <title>ObjectConverters</title>
     <meta charset="UTF-8"/>
-    <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+    <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
-      Content below this point is copied in "../../content/book/fr/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
-        <h1 id="Utilities">Classes et méthodes utilitaires</h1>
+        <h2 id="ObjectConverters">Convertisseurs d’objets</h2>
       </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>)
@@ -192,207 +116,6 @@
         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>
-
-<pre style="margin-top: 6pt">for (int i=0; i&lt;string.length();) {
-    int c = string.codePointAt(i);
-    if (Character.isWhitespace(c)) {
-        // Un espace blanc a été trouvé.
-    }
-    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>
-
-
-
-      <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>

Copied: sis/site/trunk/book/fr/utility/Utilities.html (from r1794573, sis/site/trunk/book/fr/utility.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/utility/Utilities.html?p2=sis/site/trunk/book/fr/utility/Utilities.html&p1=sis/site/trunk/book/fr/utility.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/utility.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/utility/Utilities.html [UTF-8] Tue May  9 23:04:35 2017
@@ -20,15 +20,15 @@
   under the License.
 -->
 
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
   <head>
-    <title>Classes et méthodes utilitaires</title>
+    <title>Utilities</title>
     <meta charset="UTF-8"/>
-    <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+    <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
-      Content below this point is copied in "../../content/book/fr/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
@@ -40,359 +40,9 @@
         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>
-<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>
-
-<pre style="margin-top: 6pt">for (int i=0; i&lt;string.length();) {
-    int c = string.codePointAt(i);
-    if (Character.isWhitespace(c)) {
-        // Un espace blanc a été trouvé.
-    }
-    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>
-
-
-
-      <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>
+      <xi:include href="ComparisonModes.html"/>
+      <xi:include href="ObjectConverters.html"/>
+      <xi:include href="Internationalization.html"/>
     </section>
   </body>
 </html>

Copied: sis/site/trunk/book/fr/xml/XML-ISO-19115.html (from r1794655, sis/site/trunk/book/fr/xml.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/xml/XML-ISO-19115.html?p2=sis/site/trunk/book/fr/xml/XML-ISO-19115.html&p1=sis/site/trunk/book/fr/xml.html&r1=1794655&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/xml.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/xml/XML-ISO-19115.html [UTF-8] Tue May  9 23:04:35 2017
@@ -22,114 +22,20 @@
 
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
   <head>
-    <title>Représentation des objets en XML</title>
+    <title>XML-ISO-19115</title>
     <meta charset="UTF-8"/>
-    <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+    <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
-      Content below this point is copied in "../../content/book/fr/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
       <header>
-        <h1 id="XML-ISO">Représentation des objets en <abbr>XML</abbr></h1>
+        <h2 id="XML-ISO-19115">Représentation des méta-données selon <abbr>ISO</abbr> 19115-3</h2>
       </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:
-        </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>.
@@ -207,7 +113,7 @@
         dont les instances devront être lues et écrites par <abbr>JAXB</abbr>.
       </p>
 
-      <aside>
+      <aside id="XML-SIS">
         <h3>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></h3>
         <p>
           Les paquets <code>org.apache.sis.internal.jaxb.*</code> (non-publiques)

Copied: sis/site/trunk/book/fr/xml/XML-ISO.html (from r1794573, sis/site/trunk/book/fr/xml.html)
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/xml/XML-ISO.html?p2=sis/site/trunk/book/fr/xml/XML-ISO.html&p1=sis/site/trunk/book/fr/xml.html&r1=1794573&r2=1794656&rev=1794656&view=diff
==============================================================================
--- sis/site/trunk/book/fr/xml.html [UTF-8] (original)
+++ sis/site/trunk/book/fr/xml/XML-ISO.html [UTF-8] Tue May  9 23:04:35 2017
@@ -20,15 +20,15 @@
   under the License.
 -->
 
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="fr">
   <head>
-    <title>Représentation des objets en XML</title>
+    <title>XML-ISO</title>
     <meta charset="UTF-8"/>
-    <link rel="stylesheet" type="text/css" href="../../content/book/book.css"/>
+    <link rel="stylesheet" type="text/css" href="../../../content/book/book.css"/>
   </head>
   <body>
     <!--
-      Content below this point is copied in "../../content/book/fr/developer-guide.html"
+      Content below this point is copied in "(…)/content/book/fr/developer-guide.html" file
       by the 'org.apache.sis.internal.book.Assembler' class in 'sis-build-helper' module.
     -->
     <section>
@@ -126,253 +126,7 @@
         </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>
-
-<pre class="xml"><b>&lt;MD_Metadata&gt;</b>
-  &lt;identificationInfo&gt;
-    <b>&lt;MD_DataIdentification&gt;</b>
-      &lt;citation&gt;
-        <b>&lt;CI_Citation&gt;</b>
-          &lt;citedResponsibleParty&gt;
-            <b>&lt;CI_Responsibility&gt;</b>
-              &lt;party&gt;
-                <b>&lt;CI_Party&gt;</b>
-                  &lt;contactInfo&gt;
-                    <b>&lt;CI_Contact&gt;</b>
-                      &lt;onlineResource&gt;
-                        <b>&lt;CI_OnlineResource&gt;</b>
-                          &lt;linkage&gt;
-                            &lt;URL&gt;http://www.opengeospatial.org&lt;/URL&gt;
-                          &lt;/linkage&gt;
-                        <b>&lt;/CI_OnlineResource&gt;</b>
-                      &lt;/onlineResource&gt;
-                    <b>&lt;/CI_Contact&gt;</b>
-                  &lt;/contactInfo&gt;
-                <b>&lt;/CI_Party&gt;</b>
-              &lt;/party&gt;
-            <b>&lt;/CI_Responsibility&gt;</b>
-          &lt;/citedResponsibleParty&gt;
-        <b>&lt;/CI_Citation&gt;</b>
-      &lt;/citation&gt;
-    <b>&lt;/MD_DataIdentification&gt;</b>
-  &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>
-
-<pre class="xml" style="margin-top: 6pt">&lt;MD_MetaData&gt;
-  &lt;identificationInfo&gt;
-    &lt;MD_DataIdentification id="<b>mon_id</b>"&gt;
-      &lt;!-- insérer ici des propriétés filles --&gt;
-    &lt;/MD_DataIdentification&gt;
-  &lt;/identificationInfo&gt;
-&lt;/MD_MetaData&gt;</pre>
-
-          </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>
-
-<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>(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>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>
-<pre class="xml" style="margin-top: 6pt">&lt;CI_Citation&gt;
-  &lt;series&gt;
-    &lt;CI_Series&gt;
-      &lt;!-- insérer ici des propriétés filles --&gt;
-    &lt;/CI_Series&gt;
-  &lt;/series&gt;
-&lt;/CI_Citation&gt;</pre>
-
-          </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>
+      <xi:include href="XML-ISO-19115.html"/>
     </section>
   </body>
 </html>



Mime
View raw message