sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1621147 - in /sis/site/trunk/content/book: en/developer-guide.html fr/developer-guide.html
Date Thu, 28 Aug 2014 15:00:21 GMT
Author: desruisseaux
Date: Thu Aug 28 15:00:21 2014
New Revision: 1621147

URL: http://svn.apache.org/r1621147
Log:
Reformulated some confusing paragraph in the French version, and updated English version accordingly.
The changes are based of comments provided in https://issues.apache.org/jira/browse/SIS-177
This commit contains also opportunist replacement of '-' by the Unicode long dash character.

Modified:
    sis/site/trunk/content/book/en/developer-guide.html
    sis/site/trunk/content/book/fr/developer-guide.html

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=1621147&r1=1621146&r2=1621147&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html [UTF-8] (original)
+++ sis/site/trunk/content/book/en/developer-guide.html [UTF-8] Thu Aug 28 15:00:21 2014
@@ -64,8 +64,8 @@
   <li><a href="#XML-ISO">Representing Objects in <abbr>XML</abbr></a><ul>
     <li><a href="#XML-ISO-19115">Representing Metadata According to <abbr>ISO</abbr>
19139</a><ul>
       <li><a href="#gco-id">Identification of Already-Defined Instances</a></li>
+      <li><a href="#nilReason">Representing Missing Values</a></li>
     </ul></li>
-    <li><a href="#nilReason">Representing Missing Values</a></li>
   </ul></li>
   <li><a href="#Utilities">Utility Classes and Methods</a><ul>
     <li><a href="#ComparisonMode">Comparison Modes of Objects</a></li>
@@ -115,11 +115,11 @@
   In other words, the <abbr>API</abbr> must come as near as possible to industrial
standards.
 </p><p>
   For example, one task that would benefit from a successful standardization is the accessing
of relational databases.
-  The industry has established a common language - the <abbr title="Structured Query Language">SQL</abbr>
standard - that the creators of Java
+  The industry has established a common language — the <abbr title="Structured Query
Language">SQL</abbr> standard — that the creators of Java
   have embedded in standard <abbr title="Java DataBase Connectivity">JDBC</abbr>
programming interfaces.
   Today, these interfaces are implemented by many software programs, both free and commercial.
   Like databases, methods of accessing geographic information have been standardized.
-  In this case, however, the efforts have been more recent, and their integration in software
- especially in older programs - is incomplete and not always coherent.
+  In this case, however, the efforts have been more recent, and their integration in software
— especially in older programs — is incomplete and not always coherent.
   At the time of writing, no product to our knowledge has implemented all of the specifications
in their entirety.
   However, there are many implementations that cover a fairly large spectrum.
   One of these is the Apache <abbr>SIS</abbr>® library that is described in
this document.
@@ -279,7 +279,7 @@
 <h2 id="SpecificationTypes">Different Types of Specifications</h2>
 <p>
   <abbr title="Open Geospatial Consortium">OGC</abbr> standards are specified
in several dozen documents.
-  Each document outlines a service - for example, the transformation of coordinates.
+  Each document outlines a service — for example, the transformation of coordinates.
   The function of each service is described by a collection of object classes and their interactions.
   These elements are illustrated by <abbr>UML</abbr> (Unified Modeling Language)
diagrams in specifications called "abstracts."
 </p><p>
@@ -291,10 +291,10 @@
 <ul>
   <li>
     Attempts to support an object-oriented paradigm result in a verbose approach in certain
languages
-    (notably the <abbr>XML</abbr> defined by <abbr>ISO</abbr> 19139)
- for example, in order to support polymorphism.
+    (notably the <abbr>XML</abbr> defined by <abbr>ISO</abbr> 19139)
— for example, in order to support polymorphism.
   </li>
   <li>
-    Certain data structures only exist in a few languages - for example, unions that exist
in C/C++ but not in Java.
+    Certain data structures only exist in a few languages — for example, unions that exist
in C/C++ but not in Java.
   </li>
   <li>
     Certain specifications (especially older ones) define operations which lend themselves
easily to programming languages or services,
@@ -511,10 +511,10 @@
   The <a href="http://www.geoapi.org">GeoAPI</a> project offers a set of Java
interfaces for geospatial applications.
   In a series of <code class = "GeoAPI"> org.opengis.*</code> packages, GeoAPI
defines structures representing metadata,
   reference systems of coordinates and operations that perform cartographic projections.
-  In one part that is not yet standardized - called <i>pending</i> - GeoAPI defines
structures that represent geo-referenced images,
+  In one part that is not yet standardized — called <i>pending</i> — GeoAPI
defines structures that represent geo-referenced images,
   geometries, filters that can be applied to queries, and other features.
   These interfaces closely follow the specifications of the <abbr title = "Open Geospatial
Consortium">OGC</abbr>,
-  while interpreting and adapting them to meet the needs of Java developers - for example,
conforming with naming conventions.
+  while interpreting and adapting them to meet the needs of Java developers — for example,
conforming with naming conventions.
   These interfaces benefit both client applications and libraries:
 </p>
 <ul>
@@ -548,7 +548,7 @@
     <abbr title="Common Object Request Broker Architecture">CORBA</abbr>, and
Java interfaces.
     At this time, the wave of web services had not yet eclipsed classical programming interfaces.
     The interfaces of the <abbr title="Open Geospatial Consortium">OGC</abbr>
did anticipate a networked world,
-    but invested rather - in the case of Java - in <abbr>RMI</abbr> (<i>Remote
Method Invocation</i>) technology.
+    but invested rather — in the case of Java — in <abbr>RMI</abbr> (<i>Remote
Method Invocation</i>) technology.
     As the GeoAPI project did not yet exist, we retroactively designate these historical
interfaces "<a href="http://www.geoapi.org/0.1/index.html">GeoAPI 0.1</a>."
     These interfaces already used the pacet name <code class="GeoAPI">org.opengis</code>,
which would be adopted by GeoAPI.
   </p><p>
@@ -573,7 +573,7 @@
     brought a halt to the <abbr>GO</abbr>-1 project, which in turn slowed development
on GeoAPI.
     In order to resume development, a new working group entitled "GeoAPI 3.0" was created
at the <abbr title="Open Geospatial Consortium">OGC</abbr>.
     This group took a narrower focus compared to GeoAPI 2.0, concentrating on the most stable
interfaces, and putting the others
-    - such as geometries - in a module entitled "<a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a>,"
for future consideration.
+    — such as geometries — in a module entitled "<a href="http://www.geoapi.org/geoapi-pending/index.html">pending</a>,"
for future consideration.
     <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>
@@ -598,7 +598,7 @@
   <li>
     <p>
       Some <abbr title="XML Schema Definition">XSD</abbr> schemas are much more
verbose than the original <abbr title="Unified Modeling Language">UML</abbr> schemas.
-      Converting from <abbr>XSD</abbr> schemas introduces - at least in the case
of metadata -
+      Converting from <abbr>XSD</abbr> schemas introduces — at least in the
case of metadata -
       almost double the number of interfaces actually defined by the standard, without adding
any new features.
       <abbr>XSD</abbr> schemas also define attributes specific to <abbr>XML</abbr>
documents (<code class="OGC">id</code>,
       <code class="OGC">uuid</code>, <code>xlink:href</code>, <i>etc.</i>),
that do not exist in the original <abbr>UML</abbr> diagrams,
@@ -703,7 +703,7 @@
   (<code class="GeoAPI">ProjectedCRS</code>) is defined using the <code class="OGC">SC_ProjectedCRS</code>
type of <abbr>ISO</abbr> Standard 19111.
   The second <code class="GeoAPI">@UML</code> annotation, this time applied to
the <code class="GeoAPI">getCoordinateSystem()</code> method,
   indicates that this method is defined using the <code class="OGC">coordinateSystem</code>
association of <abbr>ISO</abbr> Standard 19111,
-  and that this association is mandatory - meaning, in Java, that the method is not allowed
to return a <code>null</code> value.
+  and that this association is mandatory — meaning, in Java, that the method is not allowed
to return a <code>null</code> value.
 </p>
 
 <pre><b>package</b> <code class="GeoAPI">org.opengis.referencing.crs</code>;
@@ -742,7 +742,7 @@ System.out.println("The standard name fo
 </p>
 
 <p>
-  The reverse operation - getting the Java class and method of a standard name - is a bit
more complicated.
+  The reverse operation — getting the Java class and method of a standard name — is a
bit more complicated.
   It requires reading the <code class="GeoAPI">class-index.properties</code>
file provided in the <code class="GeoAPI">org.opengis.annotation</code> package.
   The following example reads the files just before searching for the name of the interface
corresponding to <code class="OGC">CI_Citation</code>.
   Users are always encouraged to only read this file once and then save its contents in their
application's cache.
@@ -967,7 +967,7 @@ System.out.println("The GeoAPI interface
   If the library has correctly declared its factories as services,
   users may import them by using <code>ServiceLoader</code>, as in the example
below.
   This example only takes the first factory located; if there is more than one factory -
-  for example when multiple libraries coexist - then the choice is left to the user.
+  for example when multiple libraries coexist — then the choice is left to the user.
 </p>
 
 <pre><b>import</b> <code class="GeoAPI">org.opengis.referencing.GeodeticDatum</code>;
@@ -1329,7 +1329,7 @@ System.out.println("The GeoAPI interface
   Different <abbr title="Open Geospatial Consortium">OGC</abbr>/<abbr title="International
Organization for Standardization">ISO</abbr>
   standards do not always use the same strategy to express objects in <abbr>XML</abbr>.
   <abbr>ISO</abbr> Standard 19139 in particular uses a more verbose approach
than other standards,
-  and will be the subject of its own section.
+  and will be the subject of its <a href="#XML-ISO-19115">own section</a>.
   But most <abbr>XML</abbr> formats define supplementary types and attributes
that are not part of
   the original abstract specifications.
   These supplementary attributes are usually specific to <abbr>XML</abbr> and
may not appear in the
@@ -1462,51 +1462,29 @@ System.out.println("The GeoAPI interface
 
 <p>
   The preceding example, like all documents that conform to <abbr>ISO</abbr>
19139,
-  consists of a systematic alternation of two types of <abbr>XML</abbr> elements.
-  It begins with the name of the property, which always begins with a lower-case letter (ignoring
prefixes).
-  In Java <abbr title="Application Programming Interface">API</abbr>s, each property
corresponds to a method in its parent class.
-  In the example above, <code class="OGC">gmd:identificationInfo</code> corresponds
to the method <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
-  In contrast to Java <abbr>API</abbr>s, however, <abbr>XML</abbr>
documents do not place child properties directly below.
-  Instead, these elements will only accept the following information:
+  consists of a systematic alternation of two types of <abbr>XML</abbr> elements:
 </p>
-<ul>
-  <li>
-    An element, described in the following paragraph, that will include child properties.
-  </li>
-  <li>
-    A group of attributes
-    (such as <code class="OGC">gmd:idref</code>, <code class="OGC">gco:uuidref</code>
and <code>xlink:href</code>)
-    which the <abbr title="XML Schema Definition">XSD</abbr> schemas of the <abbr
title="Open Geospatial Consortium">OGC</abbr>
-    collectively name <code class="OGC">gco:ObjectReference</code>.
-  </li>
-</ul>
-<p>
-  The value type is included under each property, unless it has been replaced with a reference
-  (the following sub-section will elaborate on this subject).
-  The value type is an <abbr>XML</abbr> element whose name always begins with
an upper-case letter,
-  ignoring prefixes.
-  In the example above we had <code class="OGC">MD_DataIdentification</code>,
-  which correspondes to the Java interface <code class="GeoAPI">DataIdentification</code>.
-  It is this <abbr>XML</abbr> element that contains the child properties.
-  This element also accepts a group of attributes (such as <code class="OGC">id</code>
and <code class="OGC">uuid</code>)
-  which the <abbr title="XML Schema Definition">XSD</abbr> schemas of the <abbr
title="Open Geospatial Consortium">OGC</abbr>
-  collectively name <code class="OGC">gco:ObjectIdentification</code>.
-  These attributes do not have dedicated Java methods, but are accessible indirectly via
the
-  <code class="SIS">IdentifiedObject</code> interface described in the following
subsection.
-</p>
-
-<aside>
-  <p><b>Naming Conventions in <abbr>XSD</abbr> Schemas</b></p>
-  <p>
-    For each element of the first group, the <abbr title="XML Schema Definition">XSD</abbr>
schemas of the
-    <abbr title="Open Geospatial Consortium">OGC</abbr> define a type whose name
ends with “<code class="OGC">_PropertyType</code>”.
-    For the second group, each element has a type whose name ends with “<code class="OGC">_Type</code>”.
-  </p>
-</aside>
+<ol>
+  <li><p>
+    It begins with the name of the property, which always begins with a lower-case letter
(ignoring prefixes).
+    In Java <abbr title="Application Programming Interface">API</abbr>s, each
property corresponds to a method in its enclosing class.
+    In the example above, <code class="OGC">gmd:identificationInfo</code>  (a
property of <code class="OGC">MD_Metadata</code> class)
+    corresponds to the method <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
+  </p></li>
+  <li><p>
+    The value type is included under each property, unless it has been replaced with a reference
+    (the following <a href="#gco-id">sub-section</a> will elaborate on this subject).
+    The value type is an <abbr>XML</abbr> element whose name always begins with
an upper-case letter,
+    ignoring prefixes.
+    In the example above we had <code class="OGC">MD_DataIdentification</code>,
+    which corresponds to the Java interface <code class="GeoAPI">DataIdentification</code>.
+    It is this <abbr>XML</abbr> element that contains the child properties.
+  </p></li>
+</ol>
 
 <p>
   In order to reduce the complexity of the libraries, GeoAPI and Apache <abbr title="Spatial
Information System">SIS</abbr>
-  only displays a single unified view of these two types of elements publicly.
+  only expose a single unified view of these two types of elements publicly.
   The public <abbr title="Application Programming Interface">API</abbr> basically
corresponds to the second group.
   However, when writing an <abbr>XML</abbr> document, elements of the first group
must be temporarily recreated.
   The corresponding classes are defined in internal <abbr title="Spatial Information System">SIS</abbr>
packages.
@@ -1525,6 +1503,17 @@ System.out.println("The GeoAPI interface
     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>
+  <p>
+    For each element of the first group listed above, the <abbr title="XML Schema Definition">XSD</abbr>
schemas of the
+    <abbr title="Open Geospatial Consortium">OGC</abbr> define a type whose name
ends with “<code class="OGC">_PropertyType</code>”.
+    For the second group, each element has a type whose name ends with “<code class="OGC">_Type</code>”.
+    The “<code class="OGC">_PropertyType</code>” elements may have a group
of attributes
+    (such as <code class="OGC">gmd:idref</code>, <code class="OGC">gco:uuidref</code>
and <code>xlink:href</code>)
+    which the <abbr>XSD</abbr> schemas collectively name <code class="OGC">gco:ObjectIdentification</code>.
+    These attributes do not have dedicated Java methods, but are accessible indirectly via
the
+    <code class="SIS">IdentifiedObject</code> interface described in the following
subsection.
+  </p>
 </aside>
 
 
@@ -1613,12 +1602,12 @@ System.out.println("The GeoAPI interface
 
 
 
-<h2 id="nilReason">Representing Missing Values</h2>
+<h3 id="nilReason">Representing Missing Values</h3>
 <p>
-  When an attribute is not defined, the corresponding GeoAPI method usually returns <code>null</code>.
-  However, things become complicated when the missing attribute is a value considered mandatory
by <abbr>ISO</abbr> Standard 19115.
-  <abbr>ISO</abbr> Standard 19139 allows for the omission of mandatory attributes
so long as the reason for the missing value is indicated.
-  The reason may be that the attribute is not applicable (<code class="OGC">inapplicable</code>),
+  When a property is not defined, the corresponding GeoAPI method usually returns <code>null</code>.
+  However, things become complicated when the missing property is a value considered mandatory
by <abbr>ISO</abbr> Standard 19115.
+  <abbr>ISO</abbr> Standard 19139 allows for the omission of mandatory properties
so long as the reason for the missing value is indicated.
+  The reason may be that the property is not applicable (<code class="OGC">inapplicable</code>),
   that the value probably exists but is not known (<code class="OGC">unknown</code>),
   that the value cannot exist (<code class="OGC">missing</code>),
   or that the value cannot be revealed (<code class="OGC">withheld</code>), <i>etc.</i>
@@ -1720,7 +1709,7 @@ System.out.println("The GeoAPI interface
     <b><code class="SIS">BY_CONTRACT</code></b> — The objects
compared must implement the same GeoAPI (or other standard)
     interface, but need not be of the same implementation class.
     Only the attributes defined in the interface are compared;
-    all other attributes specific to the implementation - even if they are public - are ignored.
+    all other attributes specific to the implementation — even if they are public — are
ignored.
   </p></li>
   <li><p>
     <b><code class="SIS">IGNORE_METADATA</code></b> — Like <code
class="SIS">BY_CONTRACT</code>,
@@ -1735,7 +1724,7 @@ System.out.println("The GeoAPI interface
 </ul>
 <p>
   The default mode, used in all <code>equals(Object)</code> methods in <abbr
title="Spatial Information System">SIS</abbr>,
-  is <code class="SIS">STRICT</code>. This mode is chosen for a safe operation
- particularly with <code>HashMap</code> —
+  is <code class="SIS">STRICT</code>. This mode is chosen for a safe operation
— particularly with <code>HashMap</code> —
   without the need to rigorously define <code>equals(Object)</code> and <code>hashCode()</code>
operations in every interface.
   With this mode, the order of objects (<code>A.equals(B)</code> or <code>B.equals(A)</code>)
is unimportant.
   It is, however, the only mode that offers this guarantee.
@@ -1783,7 +1772,7 @@ System.out.println("The GeoAPI interface
 <div class="example"><p><b>Example:</b>
   Given an environment in which the default language is English, an <code class="SIS">AngleFormat</code>
object is created to
   read angles according to French conventions.
-  If a <code>ParseException</code> is thrown when using this trainer, <code>getMessage()</code>
returns the error message in English,
+  If a <code>ParseException</code> is thrown when using this formatter, <code>getMessage()</code>
returns the error message in English,
   while <code>getLocalizedMessage()</code> returns the error message in French.
 </p></div>
 <p>
@@ -1807,7 +1796,7 @@ System.out.println("The GeoAPI interface
   <code>String</code> type would likely be localized.
   This approach allows us to defer the internationalization process to the time when a sequence
of characters is obtained,
   rather than the time when the object that contains them is created.
-  This is particularly useful for immutable classes where the instances exist in a single
copy independent of local conventions.
+  This is particularly useful for immutable classes used for creating unique instances independently
of local conventions.
 </p>
 <div class="example"><p><b>Example:</b>
   <abbr title="Spatial Information System">SIS</abbr> includes only one instance
of the <code class="GeoAPI">OperationMethod</code>
@@ -1907,7 +1896,7 @@ System.out.println("The GeoAPI interface
   These two methods differ in their interpretations of non-breaking spaces, tabs and line
breaks.
   The first method conforms to the interpretation currently used in languages such as Java,
C/C++ and <abbr>XML</abbr>,
   which considers tabs and line breaks to be blank spaces, while non-breaking spaces are
read as not blank.
-  The second method - which conforms strictly to the Unicode definition - makes the opposite
interpretation.
+  The second method — which conforms strictly to the Unicode definition — makes the opposite
interpretation.
 </p>
 <p>
   <abbr title="Spatial Information System">SIS</abbr> uses each of these methods
in different contexts.
@@ -1972,7 +1961,7 @@ System.out.println("The GeoAPI interface
   The second type is not formally considered to be a geometry;
   it extends neither <code class="OGC">GM_Object</code> nor <code class="OGC">TransfiniteSet</code>.
   It barely defines any operations besides the storing of a sequence of numbers representing
a coordinate.
-  It may therefore be a less cumbersome object.
+  It may therefore be a more lightweight object.
 </p>
 <p>
   In order to allow the <abbr title="Application Programming Interface">API</abbr>
to work equally with these two types of positions,
@@ -2072,10 +2061,10 @@ System.out.println("The GeoAPI interface
     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 object of <code class="GeoAPI">CoordinateSystemAxis</code> objects,
+    are attributes of <code class="GeoAPI">CoordinateSystemAxis</code> objects,
     indirectly associated with envelopes via the coordinate reference system.
     Apache <abbr>SIS</abbr> inspects these attributes to determine the way in
which it must perform these operations.
-    Thus, the entire axis associated with the code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>
benefit from
+    Thus, any axis associated with the code <code class="GeoAPI">RangeMeaning.WRAPAROUND</code>
benefit from
     the same treatment as does longitude.
     For example, this could be a time axis for climatological data (one "year" represents
the average temperature in all the
     months of January, followed by the average of all the months of February, etc.)
@@ -2135,7 +2124,7 @@ System.out.println("The GeoAPI interface
       The pixel values of an image may contain measures for terrain elevation.
       If the function <var>h</var> = <var>f</var>(φ,λ) allows
us to obtain (eventually, with the help of interpolations)
       the elevation <var>h</var> according the the geographic coordinate (φ,λ),
-      then the geographic envelope of the image defined by the domain - the function <var>f</var>
- is the <i>coverage</i>,
+      then the geographic envelope of the image defined by the domain — the function <var>f</var>
— is the <i>coverage</i>,
       and the set of values <var>h</var> that this function can return is the
<i>range</i>.
     </p></div>
   </li>
@@ -2171,7 +2160,7 @@ System.out.println("The GeoAPI interface
     <a href="http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29">the
common mathematical concept of an interval</a>.
     This textual representation approaches the specifications of <abbr>ISO</abbr>
Standard 31-11,
     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 inclusively to 256
exclusively.
+    For example, “[0 … 256)” represents the range of values from 0 inclusive to 256
exclusive.
   </p>
   <p>
     <code class="SIS">Range</code> objects are only indirectly associated with
coverages.

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=1621147&r1=1621146&r2=1621147&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 Aug 28 15:00:21 2014
@@ -64,8 +64,8 @@
   <li><a href="#XML-ISO">Représentation des objets en <abbr>XML</abbr></a><ul>
     <li><a href="#XML-ISO-19115">Représentation des méta-données selon <abbr>ISO</abbr>
19139</a><ul>
       <li><a href="#gco-id">Identification d’instances déjà définies</a></li>
+      <li><a href="#nilReason">Représentation de valeurs manquantes</a></li>
     </ul></li>
-    <li><a href="#nilReason">Représentation de valeurs manquantes</a></li>
   </ul></li>
   <li><a href="#Utilities">Classes et méthodes utilitaires</a><ul>
     <li><a href="#ComparisonMode">Modes de comparaisons des objets</a></li>
@@ -261,7 +261,7 @@
 <h3 id="OGC-OAB">Le conseil d’architecture (<abbr>OAB</abbr>) et le comité
technique (<abbr>TC</abbr>)</h3>
 <p>
   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>).
+  (<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 title="Open Geospatial
Consortium">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 title="Technical Committe">TC</abbr>).
@@ -1398,7 +1398,7 @@ System.out.println("L’interface GeoAPI
   <abbr title="Open Geospatial Consortium">OGC</abbr>/<abbr title="International
Organization for Standardization">ISO</abbr>
   n’emploient pas tous la même stratégie pour exprimer les objets en <abbr>XML</abbr>.
   Le standard <abbr>ISO</abbr> 19139 en particulier emploie une approche plus
verbeuse que les autres normes,
-  et fera l’objet d’une section particulière.
+  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
@@ -1460,7 +1460,7 @@ System.out.println("L’interface GeoAPI
   </p>
   <ul>
     <li>
-      <abbr title="Java Architecture for XML Binding">JAXB</abbr> pour les objets
écrits en relativement peu d’exemplaires
+      <abbr title="Java Architecture for XML Binding">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> 19139 est un exemple typique.
     </li>
@@ -1528,44 +1528,24 @@ System.out.println("L’interface GeoAPI
 
 <p>
   L’exemple précédent, comme tous les documents conformes à <abbr>ISO</abbr>
19139,
-  est constitué d’une alternance systématique de deux types d’éléments <abbr>XML</abbr>.
-  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 title="Application Programming Interface">API</abbr> Java, chaque
propriété correspond à une méthode de la classe englobante.
-  Par exemple dans l’exemple ci-haut, <code class="OGC">gmd:identificationInfo</code>
-  correspond à la méthode <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
-  Contrairement aux <abbr>API</abbr> Java toutefois, les documents <abbr>XML</abbr>
-  ne placent pas les propriétés filles directement en dessous.
-  À la place, ces éléments n’acceptent que les informations suivantes:
+  est donc constitué d’une alternance systématique de deux types d’éléments <abbr>XML</abbr>
imbriqués:
 </p>
-<ul>
-  <li>
-    Un élément, décrit dans le paragraphe suivant, qui englobera les propriétés filles.
-  </li>
-  <li>
-    Un groupe d’attributs (notamment <code class="OGC">gmd:idref</code>, <code
class="OGC">gco:uuidref</code> et <code>xlink:href</code>)
-    que les schémas <abbr title="XML Schema Definition">XSD</abbr> de l’<abbr
title="Open Geospatial Consortium">OGC</abbr>
-    nomment collectivement <code class="OGC">gco:ObjectReference</code>.
-  </li>
-</ul>
-<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 sous-section suivante approfondira ce sujet).
-  Le type de la valeur est un élément <abbr>XML</abbr> dont le nom commence
toujours par une lettre majuscule, en ignorant les préfixes.
-  Dans l’exemple ci-haut nous avions <code class="OGC">MD_DataIdentification</code>,
qui correspond à l’interface Java <code class="GeoAPI">DataIdentification</code>.
-  C’est cet élément <abbr>XML</abbr> qui contient les propriétés filles.
Cet élément accepte aussi un groupe d’attributs
-  (notamment <code class="OGC">id</code> et <code class="OGC">uuid</code>)
que les schémas <abbr title="XML Schema Definition">XSD</abbr>
-  de l’<abbr title="Open Geospatial Consortium">OGC</abbr> nomment collectivement
<code class="OGC">gco:ObjectIdentification</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>
-  <p><b>Convention de nommage dans les schémas <abbr>XSD</abbr></b></p>
-  <p>
-    Les schémas <abbr title="XML Schema Definition">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>”.
-    Pour le second groupe, chaque élément a un type dont le nom se termine par “<code
class="OGC">_Type</code>”.
-  </p>
-</aside>
+<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 title="Application Programming Interface">API</abbr> Java,
chaque propriété correspond à une méthode de la classe englobante.
+    Dans l’exemple ci-haut, <code class="OGC">gmd:identificationInfo</code>
+    (une propriété de la classe <code class="OGC">MD_Metadata</code>)
+    correspond à la méthode <code class="GeoAPI">Metadata.getIdentificationInfo()</code>.
+  </p></li>
+  <li><p>
+      Sous chaque propriété se trouve le type de la valeur, sauf si elle a été remplacée
par une référence
+      (la <a href="#gco-id">sous-section suivante</a> suivante approfondira ce
sujet).
+      Le type de la valeur est un élément <abbr>XML</abbr> dont le nom commence
toujours par une lettre majuscule, en ignorant les préfixes.
+      Dans l’exemple ci-haut nous avions <code class="OGC">MD_DataIdentification</code>,
qui correspond à l’interface Java <code class="GeoAPI">DataIdentification</code>.
+      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 title="Spatial
Information System">SIS</abbr>
@@ -1575,7 +1555,7 @@ System.out.println("L’interface GeoAPI
   doivent être temporairement recréés.
   Les classes qui y correspondent sont définies dans des paquets internes de <abbr title="Spatial
Information System">SIS</abbr>.
   Ces classes peuvent être ignorées, sauf si le développeur souhaite implémenter ses
propres
-  classes dont les instances devront être lus et écrits par <abbr title="Java Architecture
for XML Binding">JAXB</abbr>.
+  classes dont les instances devront être lues et écrites par <abbr title="Java Architecture
for XML Binding">JAXB</abbr>.
 </p>
 
 <aside>
@@ -1590,6 +1570,17 @@ System.out.println("L’interface GeoAPI
     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>
+  <p>
+    Les schémas <abbr title="XML Schema Definition">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>”.
+    Pour le second groupe, chaque élément a un type dont le nom se termine par “<code
class="OGC">_Type</code>”.
+    Les “<code class="OGC">_PropertyType</code>” peuvent avoir un groupe
d’attributs
+    (notamment <code class="OGC">gmd:idref</code>, <code class="OGC">gco:uuidref</code>
et <code>xlink:href</code>)
+    que les schémas <abbr>XSD</abbr> nomment collectivement <code class="OGC">gco:ObjectReference</code>.
+    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>
 
 
@@ -1679,12 +1670,12 @@ System.out.println("L’interface GeoAPI
 
 
 
-<h2 id="nilReason">Représentation de valeurs manquantes</h2>
+<h3 id="nilReason">Représentation de valeurs manquantes</h3>
 <p>
-  Lorsqu’un attribut n’est pas défini, la méthode correspondante de GeoAPI retourne
généralement <code>null</code>.
-  Toutefois les choses se compliquent lorsque l’attribut manquant est une valeur considérée
comme obligatoire par le standard <abbr>ISO</abbr> 19115.
-  Le standard <abbr>ISO</abbr> 19139 autorise l’omission d’attributs obligatoires
à la condition d’indiquer pourquoi la valeur est manquante.
-  Les raisons peuvent être que l’attribut ne s’applique pas (<code class="OGC">inapplicable</code>),
+  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>
@@ -1872,8 +1863,8 @@ System.out.println("L’interface GeoAPI
   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 dont les instances existent
-  en un seul exemplaire indépendamment des conventions locales.
+  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 title="Spatial Information System">SIS</abbr> une seule
instance de type
@@ -2122,7 +2113,7 @@ System.out.println("L’interface GeoAPI
 </center>
 <p>
   Les notions d’inclusion et d’intersection s’interprètent toutefois de manière légèrement
différente dans ces deux cas.
-  Dans le cas habituel où l’on ne traverse par l’antiméridien, le rectangle vert délimite
bien une région d’inclusion.
+  Dans le cas habituel où l’on ne traverse pas l’antiméridien, le rectangle vert délimite
bien une région d’inclusion.
   Les régions exclues de ce rectangle se propagent à l’infini dans toutes les directions.
   En d’autres mots, la région d’inclusion n’est pas répétée tous les 360°.
   Mais dans le cas du rectangle rouge, l’information fournie par l’enveloppe délimite
plutôt la région d’exclusion qui



Mime
View raw message