sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1705180 - in /sis: branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/ site/trunk/book/en/ site/trunk/book/fr/ site/trunk/content/book/ site/trunk/content/book/en/ site/trunk/content/book/fr/
Date Thu, 24 Sep 2015 22:28:13 GMT
Author: desruisseaux
Date: Thu Sep 24 22:28:12 2015
New Revision: 1705180

URL: http://svn.apache.org/viewvc?rev=1705180&view=rev
Log:
Use a little bit more of HTML5 semantic tags in <aside> elements.
The <aside> elements that could have been published in separated pages are replaced by <article> elements.

Modified:
    sis/branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/Assembler.java
    sis/site/trunk/book/en/coverage.html
    sis/site/trunk/book/en/geoapi.html
    sis/site/trunk/book/en/geometry.html
    sis/site/trunk/book/en/introduction.html
    sis/site/trunk/book/en/xml.html
    sis/site/trunk/book/fr/coverage.html
    sis/site/trunk/book/fr/geoapi.html
    sis/site/trunk/book/fr/geometry.html
    sis/site/trunk/book/fr/introduction.html
    sis/site/trunk/book/fr/xml.html
    sis/site/trunk/content/book/book.css
    sis/site/trunk/content/book/en/developer-guide.html
    sis/site/trunk/content/book/fr/developer-guide.html

Modified: sis/branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/Assembler.java
URL: http://svn.apache.org/viewvc/sis/branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/Assembler.java?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/Assembler.java [UTF-8] (original)
+++ sis/branches/JDK8/core/sis-build-helper/src/main/java/org/apache/sis/internal/book/Assembler.java [UTF-8] Thu Sep 24 22:28:12 2015
@@ -249,8 +249,11 @@ public final class Assembler {
     /**
      * Performs on the given node the processing documented in the class javadoc.
      * This method invokes itself recursively.
+     *
+     * @param index {@code true} for including the {@code <h1>}, etc. texts in the Table Of Content (TOC).
+     *        This is set to {@code false} when parsing the content of {@code <aside>} or {@code <article>} elements.
      */
-    private void process(Node node) throws IOException, SAXException {
+    private void process(Node node, boolean index) throws IOException, SAXException {
         switch (node.getNodeType()) {
             case Node.COMMENT_NODE: {
                 final String text = node.getNodeValue().trim();
@@ -266,6 +269,11 @@ public final class Assembler {
                         node = replaceByBody(((Element) node).getAttribute("href"), node);
                         break;
                     }
+                    case "aside":
+                    case "article": {
+                        index = false;
+                        break;
+                    }
                     case "abbr": {
                         processAbbreviation((Element) node);
                         break;
@@ -275,7 +283,9 @@ public final class Assembler {
                             final int c = name.charAt(1) - '0';
                             if (c >= 1 && c <= 9) {
                                 writtenAbbreviations.clear();
-                                appendToTableOfContent(c, ((Element) node).getAttribute("id"), node.getTextContent());
+                                if (index) {
+                                    appendToTableOfContent(c, ((Element) node).getAttribute("id"), node.getTextContent());
+                                }
                             }
                         }
                         break;
@@ -285,7 +295,7 @@ public final class Assembler {
             }
         }
         for (final Node child : toArray(node.getChildNodes())) {
-            process(child);
+            process(child, index);
         }
     }
 
@@ -329,7 +339,7 @@ public final class Assembler {
      * @throws TransformerException if an error occurred while formatting the output XML.
      */
     public void run(final File output) throws IOException, SAXException, TransformerException {
-        process(document.getDocumentElement());
+        process(document.getDocumentElement(), true);
         tableOfContent.appendChild(document.createTextNode(LINE_SEPARATOR));
         final Transformer transformer = TransformerFactory.newInstance().newTransformer();
         transformer.setOutputProperty(OutputKeys.METHOD, "xml");

Modified: sis/site/trunk/book/en/coverage.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/coverage.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/en/coverage.html (original)
+++ sis/site/trunk/book/en/coverage.html Thu Sep 24 22:28:12 2015
@@ -75,7 +75,7 @@
       <code class="OGC">CV_DiscreteCoverage</code> type.
     </p>
     <aside>
-      <p><b>SIS's <code class="SIS">Range</code> Class and its Relationship to the Standards</b></p>
+      <h2>SIS's <code class="SIS">Range</code> Class and its Relationship to the Standards</h2>
       <p>
         The distinction between the ranges of all types of values and the ranges of numeric values is represented in
         <abbr>SIS</abbr> by the <code class="SIS">Range</code> and <code class="SIS">NumberRange</code>

Modified: sis/site/trunk/book/en/geoapi.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/geoapi.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/en/geoapi.html (original)
+++ sis/site/trunk/book/en/geoapi.html Thu Sep 24 22:28:12 2015
@@ -59,8 +59,10 @@
       </p></li>
     </ul>
 
-    <aside>
-      <p><b>History</b></p>
+    <article>
+      <header>
+        <h1>GeoAPI project history</h1>
+      </header>
       <p>
         In 2001, the Open GIS Consortium (the former name of the Open Geospatial Consortium) published
         <a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> implementation specification 01-009:
@@ -98,7 +100,7 @@
         <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> became an <a href="http://www.opengeospatial.org/standards/geoapi"><abbr>OGC</abbr> standard</a> in 2011.
         This version was the first to be deployed in the <a href="http://search.maven.org/#search|ga|1|geoapi">Maven central repository</a>.
       </p>
-    </aside>
+    </article>
 
 
     <h2 id="SpecificationToInterfaces">Interface Specifications</h2>

Modified: sis/site/trunk/book/en/geometry.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/geometry.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/en/geometry.html (original)
+++ sis/site/trunk/book/en/geometry.html Thu Sep 24 22:28:12 2015
@@ -159,7 +159,7 @@
       <code class="SIS">org.apache.sis.geometry</code> package perform their calculations according to this convention.
     </p>
     <aside>
-      <p><b>Generalizing to Other Types of Axes</b></p>
+      <h5>Generalizing to Other Types of Axes</h5>
       <p>
         This section specifically relates to longitude, as it is the most usual example of a cyclic axis.
         However, in Apache <abbr>SIS</abbr> envelopes, there is no explicit mention of longitude, or of its 360° cycle.
@@ -188,7 +188,7 @@
       <cite><i>upper</i></cite> values.
     </p>
     <aside>
-      <p><b>The Special Case of the Range [+0 … -0]</b></p>
+      <h5>The Special Case of the Range [+0 … -0]</h5>
       <p>
         Java (or more generally, IEEE Standard 754) defines two values distinct from zero:
         a positive zero and a negative zero. These two values are considered equal when we compare them with the <code>==</code> operator in Java.

Modified: sis/site/trunk/book/en/introduction.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/introduction.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/en/introduction.html (original)
+++ sis/site/trunk/book/en/introduction.html Thu Sep 24 22:28:12 2015
@@ -108,8 +108,10 @@
 
 
 
-    <aside id="OGC-process">
-      <p><b><abbr>OGC</abbr> Standardization Process</b></p>
+    <article id="OGC-process">
+      <header>
+        <h1><abbr>OGC</abbr> Standardization Process</h1>
+      </header>
       <p>
         The work of the <abbr title="Open Geospatial Consortium">OGC</abbr> is done by email, teleconferences, and at <a href="http://www.opengeospatial.org/event?category=ogctcpc">in-person meetings</a>.
         The <abbr>OGC</abbr> organizes four meetings per year, each lasting five days, and hosted by member organizations that sponsor the event (companies, universities, research centres, <i>etc</i>).
@@ -124,63 +126,58 @@
         while <abbr>SWG</abbr>s require that their participants enter into an agreement not to hinder the distribution of the standard through intellectual property claims.
       </p>
 
-      <ol>
-        <li>
-          <p id="OGC-SWG"><b>Standard Working Group (<abbr>SWG</abbr>) Procedures</b></p>
-          <p>
-            In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
-            These founding members draft a charter defining the objectives of the <abbr>SWG</abbr>,
-            which must be approved by the Technical Committee of the <abbr>OGC</abbr>.
-            Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
-            Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
-            and receives on request the right to vote after several months of observation.
-          </p><p>
-            A <abbr>SWG</abbr> may contain several dozen members, but the volunteers performing the bulk of the work are usually fewer.
-            Their proposals are submitted to the entire membership of the group, who may accept them by unanimous consent.
-            Any objections must be debated, and an alternative proposed.
-            <abbr>SWG</abbr>s usually try to debate an issue until a consensus emerges rather than move ahead despite negative votes,
-            even if those opposed are in a minority.
-            The decisions of the group are then integrated into the specifications by a member who assumes the role of editor.
-          </p><p>
-            As far as possible, the working group must structure the specifications as a core around which various extensions might be built.
-            A series of tests must accompany the standard, allowing implementations to be classified by the level of test passed.
-            There must be at least one <i>reference implementation</i> that passes all the tests in order to demonstrate that the standard is usable.
-          </p><p>
-            When the standard is considered ready, the <abbr>SWG</abbr> votes on a motion proposing its submission to a vote by the higher authorities of the <abbr>OGC</abbr>.
-            This process takes several months. There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
-          </p>
-        </li><li>
-          <p id="OGC-OAB"><b>The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</b></p>
-          <p>
-            All proposals for standards are first examined by the <abbr>OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
-            This board ensures that the standard conforms to the requirements of the <abbr>OGC</abbr> in form,
-            modularization, and in terms of integration with other standards.
-            If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr>TC</abbr>).
-            This committee consists of the principal members of the <abbr>OGC</abbr>, and only they are capable of granting final approval.
-            If approved, the standard is made publicly available for comments during a period of several months.
-            At the end of this period, the <abbr title="Standard Working Group">SWG</abbr> must examine and respond to each comment.
-            The eventual modifications of the standard are submitted to the <abbr>OAB</abbr>, then the standard is published in its final form.
-            This distribution is announced in a press release by the <abbr>OGC</abbr>.
-          </p><p>
-            Certain members of the <abbr title="Open Geospatial Consortium">OGC</abbr> and the <abbr title="Technical Committee">TC</abbr>
-            also act as liaisons with the International Organization for Standardization (<abbr>ISO</abbr>).
-            Cooperation between the two organizations goes two ways:
-            the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
-            and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
-          </p>
-        </li><li>
-          <p id="OGC-RFC"><b>Procedure for the Submission of Proposals for Modification</b></p>
-          <p>
-            All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr>OGC</abbr> standards.
-            A list of current proposals for changes, along with a form for submitting new proposals, is <a href="http://www.opengeospatial.org/standards/cr">available online</a>.
-            Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
-          </p><p>
-            Some working groups use other parallel systems for submissions, for example GitHub merge requests, hosted outside of the structures of the <abbr>OGC</abbr>.
-          </p>
-        </li>
-      </ol>
-    </aside>
+      <h2 id="OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) Procedures</h2>
+      <p>
+        In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
+        These founding members draft a charter defining the objectives of the <abbr>SWG</abbr>,
+        which must be approved by the Technical Committee of the <abbr>OGC</abbr>.
+        Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
+        Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
+        and receives on request the right to vote after several months of observation.
+      </p><p>
+        A <abbr>SWG</abbr> may contain several dozen members, but the volunteers performing the bulk of the work are usually fewer.
+        Their proposals are submitted to the entire membership of the group, who may accept them by unanimous consent.
+        Any objections must be debated, and an alternative proposed.
+        <abbr>SWG</abbr>s usually try to debate an issue until a consensus emerges rather than move ahead despite negative votes,
+        even if those opposed are in a minority.
+        The decisions of the group are then integrated into the specifications by a member who assumes the role of editor.
+      </p><p>
+        As far as possible, the working group must structure the specifications as a core around which various extensions might be built.
+        A series of tests must accompany the standard, allowing implementations to be classified by the level of test passed.
+        There must be at least one <i>reference implementation</i> that passes all the tests in order to demonstrate that the standard is usable.
+      </p><p>
+        When the standard is considered ready, the <abbr>SWG</abbr> votes on a motion proposing its submission to a vote by the higher authorities of the <abbr>OGC</abbr>.
+        This process takes several months. There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
+      </p>
+
+      <h2 id="OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</h2>
+      <p>
+        All proposals for standards are first examined by the <abbr>OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
+        This board ensures that the standard conforms to the requirements of the <abbr>OGC</abbr> in form,
+        modularization, and in terms of integration with other standards.
+        If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr>TC</abbr>).
+        This committee consists of the principal members of the <abbr>OGC</abbr>, and only they are capable of granting final approval.
+        If approved, the standard is made publicly available for comments during a period of several months.
+        At the end of this period, the <abbr title="Standard Working Group">SWG</abbr> must examine and respond to each comment.
+        The eventual modifications of the standard are submitted to the <abbr>OAB</abbr>, then the standard is published in its final form.
+        This distribution is announced in a press release by the <abbr>OGC</abbr>.
+      </p><p>
+        Certain members of the <abbr title="Open Geospatial Consortium">OGC</abbr> and the <abbr title="Technical Committee">TC</abbr>
+        also act as liaisons with the International Organization for Standardization (<abbr>ISO</abbr>).
+        Cooperation between the two organizations goes two ways:
+        the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
+        and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
+      </p>
 
+      <h2 id="OGC-RFC">Procedure for the Submission of Proposals for Modification</h2>
+      <p>
+        All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr>OGC</abbr> standards.
+        A list of current proposals for changes, along with a form for submitting new proposals, is <a href="http://www.opengeospatial.org/standards/cr">available online</a>.
+        Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
+      </p><p>
+        Some working groups use other parallel systems for submissions, for example GitHub merge requests, hosted outside of the structures of the <abbr>OGC</abbr>.
+      </p>
+    </article>
 
 
     <h3 id="SpecificationTypes">Different Types of Specifications</h3>

Modified: sis/site/trunk/book/en/xml.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/en/xml.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/en/xml.html (original)
+++ sis/site/trunk/book/en/xml.html Thu Sep 24 22:28:12 2015
@@ -91,7 +91,7 @@
     </table>
 
     <aside>
-      <p><b>Tools for Reading and Writing <abbr>XML</abbr> Documents</b></p>
+      <h2>Tools for Reading and Writing <abbr>XML</abbr> Documents</h2>
       <p>
         Apache <abbr>SIS</abbr> uses different libraries to read and write different types of objects.
         The library used depends on the complexity of the object and on performance constraints.
@@ -199,14 +199,14 @@
     </p>
 
     <aside>
-      <p><b>Implementation Strategy in Apache <abbr>SIS</abbr></b></p>
+      <h3>Implementation Strategy in Apache <abbr>SIS</abbr></h3>
       <p>
         <code class="SIS">org.apache.sis.internal.jaxb.*</code> packages (non-public) define <abbr>JAXB</abbr> adaptors for all types of <abbr>ISO</abbr> objects.
         These adaptors are required anyway to allow <abbr>JAXB</abbr> to get <abbr>SIS</abbr> classes while implementing GeoAPI interfaces.
         Conveniently, <abbr>SIS</abbr> made both <abbr>JAXB</abbr> adaptors and objects wrapping the “real” object to be read or written.
         This double usage avoids having to double the number of classes (already quite high) present in the internal packages.
       </p>
-      <p><b>Naming Conventions in <abbr>XSD</abbr> Schemas</b></p>
+      <h4>Naming Conventions in <abbr>XSD</abbr> Schemas</h4>
       <p>
         For each element of the first group listed above, the <abbr>XSD</abbr> schemas of the <abbr>OGC</abbr>
         define a type whose name ends with “<code class="OGC">_PropertyType</code>”.

Modified: sis/site/trunk/book/fr/coverage.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/coverage.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/fr/coverage.html (original)
+++ sis/site/trunk/book/fr/coverage.html Thu Sep 24 22:28:12 2015
@@ -81,7 +81,7 @@
       être utilisés aussi avec des couvertures de type <code class="OGC">CV_ContinuousCoverage</code>.
     </p>
     <aside>
-      <p><b>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</b></p>
+      <h2>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</h2>
       <p>
         La distinction entre les plages de tout type de valeurs et les plages de valeurs numériques est représentée dans <abbr>SIS</abbr>
         par les classes <code class="SIS">Range</code> et <code class="SIS">NumberRange</code> respectivement.

Modified: sis/site/trunk/book/fr/geoapi.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geoapi.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geoapi.html (original)
+++ sis/site/trunk/book/fr/geoapi.html Thu Sep 24 22:28:12 2015
@@ -60,8 +60,10 @@
       </p></li>
     </ul>
 
-    <aside>
-      <p><b>Historique</b></p>
+    <article>
+      <header>
+        <h1>Historique du projet GeoAPI</h1>
+      </header>
       <p>
         En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
         <a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
@@ -101,7 +103,7 @@
         <a href="http://www.opengeospatial.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
         Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
       </p>
-    </aside>
+    </article>
 
 
     <h2 id="SpecificationToInterfaces">Des spécifications aux interfaces</h2>

Modified: sis/site/trunk/book/fr/geometry.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/geometry.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/fr/geometry.html (original)
+++ sis/site/trunk/book/fr/geometry.html Thu Sep 24 22:28:12 2015
@@ -162,7 +162,7 @@
       définies dans le paquet <code class="SIS">org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
     </p>
     <aside>
-      <p><b>Généralisation à d’autres types d’axes</b></p>
+      <h5>Généralisation à d’autres types d’axes</h5>
       <p>
         Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
         Mais dans les enveloppes de Apache <abbr>SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
@@ -192,7 +192,7 @@
       supérieures à la valeur <cite><i>upper</i></cite>.
     </p>
     <aside>
-      <p><b>Le cas particulier de la plage [+0 … -0]</b></p>
+      <h5>Le cas particulier de la plage [+0 … -0]</h5>
       <p>
         le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
         un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.

Modified: sis/site/trunk/book/fr/introduction.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/introduction.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/fr/introduction.html (original)
+++ sis/site/trunk/book/fr/introduction.html Thu Sep 24 22:28:12 2015
@@ -116,8 +116,10 @@
 
 
 
-    <aside id="OGC-process">
-      <p><b>Processus de standardisation à l’<abbr>OGC</abbr></b></p>
+    <article id="OGC-process">
+      <header>
+        <h1>Processus de standardisation à l’<abbr>OGC</abbr></h1>
+      </header>
       <p>
         Les travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr> se font par courriers électroniques,
         par conférences téléphoniques et par <a href="http://www.opengeospatial.org/event?category=ogctcpc">réunions réelles</a>.
@@ -135,66 +137,62 @@
         la diffusion du standard par des réclamations de propriétés intellectuelles.
       </p>
 
-      <ol>
-        <li>
-          <p id="OGC-SWG"><b>Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</b></p>
-          <p>
-            Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
-            Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
-            qui doit être approuvée par le comité technique de l’<abbr>OGC</abbr>.
-            Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
-            Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
-            avec attribution sur demande d’un droit de vote après quelques mois d’observation.
-          </p><p>
-            Un <abbr>SWG</abbr> peut contenir plusieurs dizaines de membres,
-            mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux.
-            Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime.
-            Les objections, s’il y en a, doivent être argumentées et une alternative proposée.
-            Les <abbr>SWG</abbr> essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme
-            plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires.
-            Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.
-          </p><p>
-            Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions.
-            Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés.
-            Au moins une <i>implémentation de référence</i> passant les tests doit exister pour démontrer que le standard est utilisable.
-          </p><p>
-            Lorsque le standard est jugé prêt, le <abbr>SWG</abbr> vote une motion
-            proposant de le soumettre au vote des instances supérieures de l’<abbr>OGC</abbr>.
-            Cette procédure nécessite plusieurs mois.
-            Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
-          </p>
-        </li><li>
-          <p id="OGC-OAB"><b>Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</b></p>
-          <p>
-            Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr>OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
-            Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
-            sur la modularisation, et en termes d’intégration avec les autres standards.
-            Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
-            Ce comité regroupe les principaux membres de l’<abbr>OGC</abbr> qui sont seuls habilités à donner le vote final.
-            En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois.
-            Au terme de cette période, le <abbr title="Standard Working Group">SWG</abbr> doit examiner et répondre à chacun des commentaires.
-            Les éventuelles modifications au standard sous soumises à l’<abbr>OAB</abbr>, puis le standard est définitivement publié.
-            Cette diffusion est alors annoncée par un communiqué de presse de l’<abbr>OGC</abbr>.
-          </p><p>
-            Certains membres de l’<abbr title="Open Geospatial Consortium">OGC</abbr> et du <abbr title="Technical Committe">TC</abbr>
-            assurent aussi la liaison avec l’organisation internationale de normalisation (<abbr title="International Organization for Standardization">ISO</abbr>).
-            La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
-            laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
-          </p>
-        </li><li>
-          <p id="OGC-RFC"><b>Procédure de soumission de propositions de modifications</b></p>
-          <p>
-            Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr>OGC</abbr>.
-            Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
-            sont <a href="http://www.opengeospatial.org/standards/cr">disponibles en ligne</a>.
-            Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
-          </p><p>
-            Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
-            hébergés en dehors des structures de l’<abbr>OGC</abbr>.
-          </p>
-        </li>
-      </ol>
-    </aside>
+      <h2 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h2>
+      <p>
+        Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
+        Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
+        qui doit être approuvée par le comité technique de l’<abbr>OGC</abbr>.
+        Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
+        Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
+        avec attribution sur demande d’un droit de vote après quelques mois d’observation.
+      </p><p>
+        Un <abbr>SWG</abbr> peut contenir plusieurs dizaines de membres,
+        mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux.
+        Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime.
+        Les objections, s’il y en a, doivent être argumentées et une alternative proposée.
+        Les <abbr>SWG</abbr> essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme
+        plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires.
+        Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.
+      </p><p>
+        Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions.
+        Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés.
+        Au moins une <i>implémentation de référence</i> passant les tests doit exister pour démontrer que le standard est utilisable.
+      </p><p>
+        Lorsque le standard est jugé prêt, le <abbr>SWG</abbr> vote une motion
+        proposant de le soumettre au vote des instances supérieures de l’<abbr>OGC</abbr>.
+        Cette procédure nécessite plusieurs mois.
+        Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
+      </p>
+
+      <h2 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h2>
+      <p>
+        Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr>OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
+        Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
+        sur la modularisation, et en termes d’intégration avec les autres standards.
+        Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
+        Ce comité regroupe les principaux membres de l’<abbr>OGC</abbr> qui sont seuls habilités à donner le vote final.
+        En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois.
+        Au terme de cette période, le <abbr title="Standard Working Group">SWG</abbr> doit examiner et répondre à chacun des commentaires.
+        Les éventuelles modifications au standard sous soumises à l’<abbr>OAB</abbr>, puis le standard est définitivement publié.
+        Cette diffusion est alors annoncée par un communiqué de presse de l’<abbr>OGC</abbr>.
+      </p><p>
+        Certains membres de l’<abbr title="Open Geospatial Consortium">OGC</abbr> et du <abbr title="Technical Committe">TC</abbr>
+        assurent aussi la liaison avec l’organisation internationale de normalisation (<abbr title="International Organization for Standardization">ISO</abbr>).
+        La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
+        laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
+      </p>
+
+      <h2 id="OGC-RFC">Procédure de soumission de propositions de modifications</h2>
+      <p>
+        Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr>OGC</abbr>.
+        Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
+        sont <a href="http://www.opengeospatial.org/standards/cr">disponibles en ligne</a>.
+        Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
+      </p><p>
+        Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
+        hébergés en dehors des structures de l’<abbr>OGC</abbr>.
+      </p>
+    </article>
 
 
 

Modified: sis/site/trunk/book/fr/xml.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/book/fr/xml.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/book/fr/xml.html (original)
+++ sis/site/trunk/book/fr/xml.html Thu Sep 24 22:28:12 2015
@@ -93,7 +93,7 @@
     </table>
 
     <aside>
-      <p><b>Outils de lecture et d’écriture de documents <abbr>XML</abbr></b></p>
+      <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.
@@ -202,7 +202,7 @@
     </p>
 
     <aside>
-      <p><b>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></b></p>
+      <h3>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></h3>
       <p>
         Les paquets <code class="SIS">org.apache.sis.internal.jaxb.*</code> (non-publiques)
         définissent des adaptateurs <abbr>JAXB</abbr> pour tous les types d’objet <abbr>ISO</abbr>.
@@ -213,7 +213,7 @@
         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>
-      <p><b>Convention de nommage dans les schémas <abbr>XSD</abbr></b></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>”.

Modified: sis/site/trunk/content/book/book.css
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/book.css?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/content/book/book.css (original)
+++ sis/site/trunk/content/book/book.css Thu Sep 24 22:28:12 2015
@@ -30,7 +30,8 @@ ul.toc ul {
 /*
  * Chapters and sections titles (excluding the book titles).
  */
-h1 {
+body > header > h1,
+section > header > h1 {
   margin-top:          120pt;
   background-color:    #99AAFF;
   border-top-color:    #0000CC;
@@ -43,17 +44,20 @@ h1 {
   padding-top:         4pt;
 }
 
-h2 {
+body > h2,
+section > h2 {
   margin-top:          40pt;
   border-bottom-style: solid;
   border-bottom-width: 2pt;
 }
 
-h3 {
+body > h3,
+section > h3 {
   margin-top: 24pt;
 }
 
-h4 {
+body > h4,
+section > h4 {
   margin-top: 15pt;
 }
 
@@ -67,7 +71,7 @@ div.example {
   font-size:    smaller;
 }
 
-aside {
+article, aside {
   margin-left:     45pt;
   margin-right:    45pt;
   margin-top:      15pt;
@@ -81,6 +85,21 @@ aside {
   font-size:        smaller;
 }
 
+aside h1, article h1,
+aside h2, article h2,
+aside h3, article h3,
+aside h4, article h4,
+aside h5, article h5 {
+  font-size: medium;
+  margin-top: 9pt;
+  margin-bottom: 9pt;
+}
+
+aside h1, article h1 {
+  font-size: large;
+  margin-top: 12pt;
+}
+
 caption {
   color:          #0086E0;
   font-weight:    bold;

Modified: sis/site/trunk/content/book/en/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/en/developer-guide.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html (original)
+++ sis/site/trunk/content/book/en/developer-guide.html Thu Sep 24 22:28:12 2015
@@ -148,8 +148,10 @@ and <a href="http://en.wikipedia.org/wik
 
 
 
-<aside id="OGC-process">
-<p><b><abbr>OGC</abbr> Standardization Process</b></p>
+<article id="OGC-process">
+<header>
+<h1><abbr>OGC</abbr> Standardization Process</h1>
+</header>
 <p>
 The work of the <abbr title="Open Geospatial Consortium">OGC</abbr> is done by email, teleconferences, and at <a href="http://www.opengeospatial.org/event?category=ogctcpc">in-person meetings</a>.
 The <abbr>OGC</abbr> organizes four meetings per year, each lasting five days, and hosted by member organizations that sponsor the event (companies, universities, research centres, <i>etc</i>).
@@ -164,13 +166,11 @@ A working group is proposed as a <i>Doma
 while <abbr>SWG</abbr>s require that their participants enter into an agreement not to hinder the distribution of the standard through intellectual property claims.
 </p>
 
-<ol>
-<li>
-<p id="OGC-SWG"><b>Standard Working Group (<abbr>SWG</abbr>) Procedures</b></p>
+<h2 id="OGC-SWG">Standard Working Group (<abbr>SWG</abbr>) Procedures</h2>
 <p>
 In order to be accepted, a standardization project must be supported by a minimum number of members belonging to distinct organizations.
 These founding members draft a charter defining the objectives of the <abbr>SWG</abbr>,
-which must be approved by the Technical Committee of the <abbr>OGC</abbr>.
+which must be approved by the Technical Committee of the <abbr title="Open Geospatial Consortium">OGC</abbr>.
 Each founding member is endowed with the right to vote, with a limit of one voting member per organization.
 Each new member that wishes to join the <abbr>SWG</abbr> after its creation is granted the role of observer,
 and receives on request the right to vote after several months of observation.
@@ -189,10 +189,10 @@ There must be at least one <i>reference
 When the standard is considered ready, the <abbr>SWG</abbr> votes on a motion proposing its submission to a vote by the higher authorities of the <abbr>OGC</abbr>.
 This process takes several months. There is a faster process for approving <i>de facto</i> standards, but it is applied sparingly.
 </p>
-</li><li>
-<p id="OGC-OAB"><b>The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</b></p>
+
+<h2 id="OGC-OAB">The Architecture Board (<abbr>OAB</abbr>) and the Technical Committee (<abbr>TC</abbr>)</h2>
 <p>
-All proposals for standards are first examined by the <abbr>OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
+All proposals for standards are first examined by the <abbr title="Open Geospatial Consortium">OGC</abbr> Architecture Board (<abbr>OAB</abbr>).
 This board ensures that the standard conforms to the requirements of the <abbr>OGC</abbr> in form,
 modularization, and in terms of integration with other standards.
 If the <abbr>OAB</abbr> approves it, the standard is next submitted to a vote by the members of the Technical Committee (<abbr>TC</abbr>).
@@ -208,19 +208,16 @@ Cooperation between the two organization
 the <abbr>OGC</abbr> adopts the <abbr>ISO</abbr> standards as a foundation on which to develop new standards,
 and certain <abbr>OGC</abbr> standards become <abbr>ISO</abbr> standards.
 </p>
-</li><li>
-<p id="OGC-RFC"><b>Procedure for the Submission of Proposals for Modification</b></p>
+
+<h2 id="OGC-RFC">Procedure for the Submission of Proposals for Modification</h2>
 <p>
-All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr>OGC</abbr> standards.
+All users, whether or not they are members of the Open Geospatial Consortium, may propose modifications to <abbr title="Open Geospatial Consortium">OGC</abbr> standards.
 A list of current proposals for changes, along with a form for submitting new proposals, is <a href="http://www.opengeospatial.org/standards/cr">available online</a>.
 Each proposal is reviewed by the <abbr title="Standard Working Group">SWG</abbr>.
 </p><p>
 Some working groups use other parallel systems for submissions, for example GitHub merge requests, hosted outside of the structures of the <abbr>OGC</abbr>.
 </p>
-</li>
-</ol>
-</aside>
-
+</article>
 
 
 <h3 id="SpecificationTypes">Different Types of Specifications</h3>
@@ -521,11 +518,13 @@ and simply get a null value until a new
 </p></li>
 </ul>
 
-<aside>
-<p><b>History</b></p>
+<article>
+<header>
+<h1>GeoAPI project history</h1>
+</header>
 <p>
 In 2001, the Open GIS Consortium (the former name of the Open Geospatial Consortium) published
-<a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> implementation specification 01-009:
+<a href="http://www.opengeospatial.org/standards/ct"><abbr title="Open Geospatial Consortium">OGC</abbr> implementation specification 01-009:
 <cite>Coordinate Transformation Services</cite></a>.
 This specification, developed by the Computer Aided Development Corporation (Cadcorp),
 was accompanied by <abbr title="Component Object Model">COM</abbr>, <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, and Java interfaces.
@@ -536,7 +535,7 @@ As the GeoAPI project did not yet exist,
 These interfaces already used the package name <code class="GeoAPI">org.opengis</code>, which would be adopted by GeoAPI.
 </p><p>
 In 2002, developers of free projects launched a
-<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">call for the creation of a geospatial <abbr>API</abbr></a>.
+<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">call for the creation of a geospatial <abbr title="Application Programming Interface">API</abbr></a>.
 The initial proposal attracted the interest of at least five free projects.
 The project was created using <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
 which has since hosted the source code in a <a href="http://www.geoapi.org/source-repository.html">Subversion repository</a>.
@@ -560,7 +559,7 @@ This group took a narrower focus compare
 <a href="http://www.geoapi.org/3.0/index.html">GeoAPI 3.0</a> became an <a href="http://www.opengeospatial.org/standards/geoapi"><abbr>OGC</abbr> standard</a> in 2011.
 This version was the first to be deployed in the <a href="http://search.maven.org/#search|ga|1|geoapi">Maven central repository</a>.
 </p>
-</aside>
+</article>
 
 
 <h2 id="SpecificationToInterfaces">Interface Specifications</h2>
@@ -1347,9 +1346,9 @@ These prefixes are defined in the <code
 </table>
 
 <aside>
-<p><b>Tools for Reading and Writing <abbr>XML</abbr> Documents</b></p>
+<h2>Tools for Reading and Writing <abbr>XML</abbr> Documents</h2>
 <p>
-Apache <abbr>SIS</abbr> uses different libraries to read and write different types of objects.
+Apache <abbr title="Spatial Information System">SIS</abbr> uses different libraries to read and write different types of objects.
 The library used depends on the complexity of the object and on performance constraints.
 For example, <abbr title="Java Architecture for XML Binding">JAXB</abbr> annotations have the advantage of being close to code,
 which makes it easier to maintain mapping between Java and <abbr>XML</abbr>.
@@ -1359,7 +1358,7 @@ In general, Apache <abbr>SIS</abbr> uses
 <ul>
 <li>
 <abbr>JAXB</abbr> for objects that do not occur very often in <abbr>XML</abbr> documents, but with complex structures and deep hierarchies.
-The metadata set in <abbr>ISO</abbr> 19115-3 standard is a typical example
+The metadata set in <abbr title="International Organization for Standardization">ISO</abbr> 19115-3 standard is a typical example
 </li>
 <li>
 <abbr>SAX</abbr> for objects that are relatively simple, but which may exist in very large numbers.
@@ -1455,14 +1454,14 @@ These classes may be ignored, unless the
 </p>
 
 <aside>
-<p><b>Implementation Strategy in Apache <abbr>SIS</abbr></b></p>
+<h3>Implementation Strategy in Apache <abbr title="Spatial Information System">SIS</abbr></h3>
 <p>
-<code class="SIS">org.apache.sis.internal.jaxb.*</code> packages (non-public) define <abbr>JAXB</abbr> adaptors for all types of <abbr>ISO</abbr> objects.
+<code class="SIS">org.apache.sis.internal.jaxb.*</code> packages (non-public) define <abbr title="Java Architecture for XML Binding">JAXB</abbr> adaptors for all types of <abbr title="International Organization for Standardization">ISO</abbr> objects.
 These adaptors are required anyway to allow <abbr>JAXB</abbr> to get <abbr>SIS</abbr> classes while implementing GeoAPI interfaces.
 Conveniently, <abbr>SIS</abbr> made both <abbr>JAXB</abbr> adaptors and objects wrapping the “real” object to be read or written.
 This double usage avoids having to double the number of classes (already quite high) present in the internal packages.
 </p>
-<p><b>Naming Conventions in <abbr title="XML Schema Definition">XSD</abbr> Schemas</b></p>
+<h4>Naming Conventions in <abbr title="XML Schema Definition">XSD</abbr> Schemas</h4>
 <p>
 For each element of the first group listed above, the <abbr>XSD</abbr> schemas of the <abbr title="Open Geospatial Consortium">OGC</abbr>
 define a type whose name ends with “<code class="OGC">_PropertyType</code>”.
@@ -2009,10 +2008,10 @@ All the <code class="SIS">add(…)</c
 <code class="SIS">org.apache.sis.geometry</code> package perform their calculations according to this convention.
 </p>
 <aside>
-<p><b>Generalizing to Other Types of Axes</b></p>
+<h5>Generalizing to Other Types of Axes</h5>
 <p>
 This section specifically relates to longitude, as it is the most usual example of a cyclic axis.
-However, in Apache <abbr>SIS</abbr> envelopes, there is no explicit mention of longitude, or of its 360° cycle.
+However, in Apache <abbr title="Spatial Information System">SIS</abbr> envelopes, there is no explicit mention of longitude, or of its 360° cycle.
 The characteristics of the range of values of each axis (its extremum, units, type of cycle, etc.)
 are attributes of <code class="GeoAPI">CoordinateSystemAxis</code> objects,
 indirectly associated with envelopes via the coordinate reference system.
@@ -2038,11 +2037,11 @@ coordinates within the desired limits, s
 <cite><i>upper</i></cite> values.
 </p>
 <aside>
-<p><b>The Special Case of the Range [+0 … -0]</b></p>
+<h5>The Special Case of the Range [+0 … -0]</h5>
 <p>
 Java (or more generally, IEEE Standard 754) defines two values distinct from zero:
 a positive zero and a negative zero. These two values are considered equal when we compare them with the <code>==</code> operator in Java.
-But in <abbr>SIS</abbr> envelopes, they may actually return opposite results for axes using <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
+But in <abbr title="Spatial Information System">SIS</abbr> envelopes, they may actually return opposite results for axes using <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
 An envelope whose range is [0 … 0], [-0 … -0] or [-0 … +0] would normally be considered an empty envelope,
 but the [+0 … -0] range would in fact be considered to include the entire set of values all around the world.
 This behaviour conforms to the definition of <code class="SIS">lowerCorner</code> and <code class="SIS">upperCorner</code>,
@@ -2103,14 +2102,14 @@ Thus, since interpolations are only poss
 <code class="OGC">CV_DiscreteCoverage</code> type.
 </p>
 <aside>
-<p><b>SIS's <code class="SIS">Range</code> Class and its Relationship to the Standards</b></p>
+<h2>SIS's <code class="SIS">Range</code> Class and its Relationship to the Standards</h2>
 <p>
 The distinction between the ranges of all types of values and the ranges of numeric values is represented in
-<abbr>SIS</abbr> by the <code class="SIS">Range</code> and <code class="SIS">NumberRange</code>
+<abbr title="Spatial Information System">SIS</abbr> by the <code class="SIS">Range</code> and <code class="SIS">NumberRange</code>
 classes respectively.
 The <code class="SIS">NumberRange</code> is used more often, and is also the one that most closely approaches the
 <a href="http://en.wikipedia.org/wiki/Interval_%28mathematics%29">the common mathematical concept of an interval</a>.
-This textual representation approaches the specifications of <abbr>ISO</abbr> 31-11 standard,
+This textual representation approaches the specifications of <abbr title="International Organization for Standardization">ISO</abbr> 31-11 standard,
 except that the comma is replaced by the character “…” as the separator of minimal and maximal values.
 For example, “[0 … 256)” represents the range of values from 0 inclusive to 256 exclusive.
 </p>

Modified: sis/site/trunk/content/book/fr/developer-guide.html
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/book/fr/developer-guide.html?rev=1705180&r1=1705179&r2=1705180&view=diff
==============================================================================
--- sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/content/book/fr/developer-guide.html [UTF-8] Thu Sep 24 22:28:12 2015
@@ -156,8 +156,10 @@ D’autres exemples de standards de fait
 
 
 
-<aside id="OGC-process">
-<p><b>Processus de standardisation à l’<abbr>OGC</abbr></b></p>
+<article id="OGC-process">
+<header>
+<h1>Processus de standardisation à l’<abbr>OGC</abbr></h1>
+</header>
 <p>
 Les travaux de l’<abbr title="Open Geospatial Consortium">OGC</abbr> se font par courriers électroniques,
 par conférences téléphoniques et par <a href="http://www.opengeospatial.org/event?category=ogctcpc">réunions réelles</a>.
@@ -175,13 +177,11 @@ tandis que les <abbr>SWG</abbr> nécessi
 la diffusion du standard par des réclamations de propriétés intellectuelles.
 </p>
 
-<ol>
-<li>
-<p id="OGC-SWG"><b>Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</b></p>
+<h2 id="OGC-SWG">Fonctionnement des groupes de travail (<abbr>SWG</abbr>)</h2>
 <p>
 Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes.
 Ces membres fondateurs rédigent une charte définissant les objectifs du <abbr>SWG</abbr>,
-qui doit être approuvée par le comité technique de l’<abbr>OGC</abbr>.
+qui doit être approuvée par le comité technique de l’<abbr title="Open Geospatial Consortium">OGC</abbr>.
 Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation.
 Tout nouveau membre qui souhaite joindre le <abbr>SWG</abbr> après sa création se verra attribué un rôle d’observateur,
 avec attribution sur demande d’un droit de vote après quelques mois d’observation.
@@ -203,10 +203,10 @@ proposant de le soumettre au vote des in
 Cette procédure nécessite plusieurs mois.
 Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.
 </p>
-</li><li>
-<p id="OGC-OAB"><b>Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</b></p>
+
+<h2 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité technique (<abbr>TC</abbr>)</h2>
 <p>
-Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr>OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
+Toute proposition de standard est d’abord examinée par le conseil d’architecture (<i><abbr title="Open Geospatial Consortium">OGC</abbr> Architecture Board</i> — <abbr>OAB</abbr>).
 Ce conseil vérifie que le standard répond aux exigences de l’<abbr>OGC</abbr> sur la forme,
 sur la modularisation, et en termes d’intégration avec les autres standards.
 Si l’<abbr>OAB</abbr> donne son aval, le standard est alors soumis au vote des membres du comité technique (<abbr>TC</abbr>).
@@ -221,10 +221,10 @@ assurent aussi la liaison avec l’organ
 La coopération entre les deux organismes va dans les deux sens: l’<abbr>OGC</abbr> adopte les standards <abbr>ISO</abbr> comme base sur
 laquelle développer de nouveaux standards, et certains de ces nouveaux standards <abbr>OGC</abbr> deviennent des standards <abbr>ISO</abbr>.
 </p>
-</li><li>
-<p id="OGC-RFC"><b>Procédure de soumission de propositions de modifications</b></p>
+
+<h2 id="OGC-RFC">Procédure de soumission de propositions de modifications</h2>
 <p>
-Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr>OGC</abbr>.
+Tout utilisateur, qu’il soit membre ou non du consortium <i>Open Geospatial</i>, peut proposer des modifications à des standards <abbr title="Open Geospatial Consortium">OGC</abbr>.
 Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles,
 sont <a href="http://www.opengeospatial.org/standards/cr">disponibles en ligne</a>.
 Chaque proposition est revue par le <abbr title="Standard Working Group">SWG</abbr>.
@@ -232,9 +232,7 @@ Chaque proposition est revue par le <abb
 Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub,
 hébergés en dehors des structures de l’<abbr>OGC</abbr>.
 </p>
-</li>
-</ol>
-</aside>
+</article>
 
 
 
@@ -552,11 +550,13 @@ quitte à obtenir une valeur nulle en at
 </p></li>
 </ul>
 
-<aside>
-<p><b>Historique</b></p>
+<article>
+<header>
+<h1>Historique du projet GeoAPI</h1>
+</header>
 <p>
 En 2001, le consortium <i>Open GIS</i> (l’ancien nom du consortium <i>Open Geospatial</i>) publia la spécification d’implémentation
-<a href="http://www.opengeospatial.org/standards/ct"><abbr>OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
+<a href="http://www.opengeospatial.org/standards/ct"><abbr title="Open Geospatial Consortium">OGC</abbr> 01-009: <cite>Coordinate Transformation Services</cite></a>.
 Cette spécification, élaborée par <i>Computer Aided Development Corporation</i> (Cadcorp),
 était accompagnée d’interfaces <abbr title="Component Object Model">COM</abbr>, <abbr title="Common Object Request Broker Architecture">CORBA</abbr> et Java.
 À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques.
@@ -567,7 +567,7 @@ Bien que le projet GeoAPI n’existait p
 Ces interfaces utilisaient déjà le nom de paquet <code class="GeoAPI">org.opengis</code>, qui sera adopté par GeoAPI.
 </p><p>
 En 2002, des développeurs de projets libres ont lancé un
-<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr>API</abbr> géo-spatial</a>.
+<a href="http://web.archive.org/web/20030509104308/http://digitalearth.org/story/2002/10/10/55046/206">appel à la création d’un <abbr title="Application Programming Interface">API</abbr> géo-spatial</a>.
 La proposition initiale suscita l’intérêt d’au moins cinq projets libres.
 Le projet fut créé sur <a href="http://sourceforge.net/projects/geoapi/">SourceForge</a>,
 qui héberge depuis lors le code source dans un <a href="http://www.geoapi.org/source-repository.html">dépôt Subversion</a>.
@@ -593,7 +593,7 @@ pour considérations futures. <a href="h
 <a href="http://www.opengeospatial.org/standards/geoapi">standard <abbr>OGC</abbr></a> en 2011.
 Cette version a été la première à être déployée dans le <a href="http://search.maven.org/#search|ga|1|geoapi">dépôt central de Maven</a>.
 </p>
-</aside>
+</article>
 
 
 <h2 id="SpecificationToInterfaces">Des spécifications aux interfaces</h2>
@@ -1407,9 +1407,9 @@ Ces préfixes sont définis dans la clas
 </table>
 
 <aside>
-<p><b>Outils de lecture et d’écriture de documents <abbr>XML</abbr></b></p>
+<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.
+Apache <abbr title="Spatial Information System">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>.
@@ -1420,7 +1420,7 @@ De manière générale, Apache <abbr>SIS
 <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.
+L’ensemble des méta-données <abbr title="International Organization for Standardization">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.
@@ -1516,10 +1516,10 @@ dont les instances devront être lues et
 </p>
 
 <aside>
-<p><b>Stratégie d’implémentation dans Apache <abbr>SIS</abbr></b></p>
+<h3>Stratégie d’implémentation dans Apache <abbr title="Spatial Information System">SIS</abbr></h3>
 <p>
 Les paquets <code class="SIS">org.apache.sis.internal.jaxb.*</code> (non-publiques)
-définissent des adaptateurs <abbr>JAXB</abbr> pour tous les types d’objet <abbr>ISO</abbr>.
+définissent des adaptateurs <abbr title="Java Architecture for XML Binding">JAXB</abbr> pour tous les types d’objet <abbr title="International Organization for Standardization">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>
@@ -1527,7 +1527,7 @@ et des objets enveloppants le “vrai”
 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>
-<p><b>Convention de nommage dans les schémas <abbr title="XML Schema Definition">XSD</abbr></b></p>
+<h4>Convention de nommage dans les schémas <abbr title="XML Schema Definition">XSD</abbr></h4>
 <p>
 Les schémas <abbr>XSD</abbr> de l’<abbr title="Open Geospatial Consortium">OGC</abbr> définissent pour chaque élément du premier groupe
 un type dont le nom se termine par “<code class="OGC">_PropertyType</code>”.
@@ -2082,10 +2082,10 @@ Toutes les fonctions <code class="SIS">a
 définies dans le paquet <code class="SIS">org.apache.sis.geometry</code> effectuent leurs calculs selon cette convention.
 </p>
 <aside>
-<p><b>Généralisation à d’autres types d’axes</b></p>
+<h5>Généralisation à d’autres types d’axes</h5>
 <p>
 Cette section nomme spécifiquement la longitude car il constitue le cas le plus courant d’axe cyclique.
-Mais dans les enveloppes de Apache <abbr>SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
+Mais dans les enveloppes de Apache <abbr title="Spatial Information System">SIS</abbr>, il n’est fait nul part mention explicite du cas de la longitude, ni de son cycle de 360°.
 Les caractéristiques de la plage de valeurs de chaque axe (ses extremums, unités, type de cycle, <i>etc.</i>)
 sont des attributs des objets <code class="GeoAPI">CoordinateSystemAxis</code>,
 indirectement associés aux enveloppes via le système de référence des coordonnées.
@@ -2112,11 +2112,11 @@ dans les limites attendues, au prix parf
 supérieures à la valeur <cite><i>upper</i></cite>.
 </p>
 <aside>
-<p><b>Le cas particulier de la plage [+0 … -0]</b></p>
+<h5>Le cas particulier de la plage [+0 … -0]</h5>
 <p>
 le Java (ou de manière plus générale, la norme IEEE 754) définit deux valeurs distinctes de zéro:
 un zéro positif et un zéro négatif. Ces deux valeurs sont considérées égales lorsqu’on les compares avec l’opérateur <code>==</code> du Java.
-Mais dans les enveloppes de <abbr>SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
+Mais dans les enveloppes de <abbr title="Spatial Information System">SIS</abbr>, ils peuvent mener à des résultats opposés pour les axes ayant <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>.
 Une enveloppe dont la plage est [0 … 0], [-0 … -0] ou [-0 … +0] sera bien considérée comme une enveloppe vide,
 mais la page [+0 … -0] sera au contraire considérée comme incluant la totalité des valeurs, jusqu’à l’infini.
 Ce comportement est conforme à la définition de <code class="SIS">lowerCorner</code> et <code class="SIS">upperCorner</code>
@@ -2183,13 +2183,13 @@ En revanche, les <i>ranges</i> de valeur
 être utilisés aussi avec des couvertures de type <code class="OGC">CV_ContinuousCoverage</code>.
 </p>
 <aside>
-<p><b>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</b></p>
+<h2>La classe <code class="SIS">Range</code> de SIS et sa relation avec les standards</h2>
 <p>
-La distinction entre les plages de tout type de valeurs et les plages de valeurs numériques est représentée dans <abbr>SIS</abbr>
+La distinction entre les plages de tout type de valeurs et les plages de valeurs numériques est représentée dans <abbr title="Spatial Information System">SIS</abbr>
 par les classes <code class="SIS">Range</code> et <code class="SIS">NumberRange</code> respectivement.
 La classe <code class="SIS">NumberRange</code> est la plus utilisée, et elle est aussi celle qui se rapproche le plus de la
 <a href="http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29">notion mathématique usuelle d’un intervalle</a>.
-Se représentation textuelle se rapproche des spécifications du standard <abbr>ISO</abbr> 31-11,
+Se représentation textuelle se rapproche des spécifications du standard <abbr title="International Organization for Standardization">ISO</abbr> 31-11,
 excepté que la virgule est remplacée par le caractère “…” comme séparateur des valeurs minimales et maximales.
 Par exemple “[0 … 256)” représente la plage des valeurs 0 inclusivement à 256 exclusivement.
 </p>



Mime
View raw message