Author: desruisseaux
Date: Wed May 25 18:10:58 2016
New Revision: 1745526
URL: http://svn.apache.org/viewvc?rev=1745526&view=rev
Log:
But the article about OGC standardisation process and historical note in a
<details> HTML 5 block.
Modified:
sis/site/trunk/book/en/introduction.html
sis/site/trunk/book/fr/introduction.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/site/trunk/book/en/introduction.html
URL:
http://svn.apache.org/viewvc/sis/site/trunk/book/en/introduction.html?rev=1745526&r1=1745525&r2=1745526&view=diff
==============================================================================
--- sis/site/trunk/book/en/introduction.html (original)
+++ sis/site/trunk/book/en/introduction.html Wed May 25 18:10:58 2016
@@ -108,76 +108,79 @@
- <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>).
- The host continent alternates between Europe and North America, with a
growing presence in Asia since 2011.
- These meetings are usually attended by between 50 and 100 participants
from among the hundreds of members of the <abbr>OGC</abbr>.
- Some participants are present at almost all the meetings, forming the
pillars of the organization.
- The meetings of the <abbr>OGC</abbr> offer opportunities for exchange
among members from diverse backgrounds.
- </p><p>
- The creation of a <abbr>OGC</abbr> standard begins with a gathering of
organizations or individuals with a common interest in an issue.
- A working group is proposed as a <i>Domain Working Group</i>
(<abbr>DWG</abbr>) or as a <i>Standard Working Group</i> (<abbr>SWG</abbr>).
- <abbr>DWG</abbr>s are open to all members of the <abbr>OGC</abbr>,
- 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>
-
- <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>
+ <details>
+ <summary>More about standardization process</summary>
+ <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>).
+ The host continent alternates between Europe and North America, with
a growing presence in Asia since 2011.
+ These meetings are usually attended by between 50 and 100
participants from among the hundreds of members of the <abbr>OGC</abbr>.
+ Some participants are present at almost all the meetings, forming
the pillars of the organization.
+ The meetings of the <abbr>OGC</abbr> offer opportunities for
exchange among members from diverse backgrounds.
+ </p><p>
+ The creation of a <abbr>OGC</abbr> standard begins with a gathering
of organizations or individuals with a common interest in an issue.
+ A working group is proposed as a <i>Domain Working Group</i>
(<abbr>DWG</abbr>) or as a <i>Standard Working Group</i> (<abbr>SWG</abbr>).
+ <abbr>DWG</abbr>s are open to all members of the <abbr>OGC</abbr>,
+ 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>
+
+ <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>
+ </details>
<h3 id="SpecificationTypes">Types of Specifications</h3>
@@ -196,42 +199,47 @@
- <article id="implementation-standard">
- <header>
- <h1>Historical note</h1>
- </header>
- <p>
- At the turn of the millennium, the abstract specifications were
explicitly concretized in <i>implementation specifications</i>.
- The term âimplementationâ is used here in the sense of all types
of interfaces (Java or others) derived from
- <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not
implementations in the Java sense.
- Such specifications existed for <abbr title="Structured Query
Language">SQL</abbr>,
- <abbr title="Common Object Request Broker Architecture">CORBA</abbr>,
<abbr title="Component Object Model">COM</abbr>, and Java languages.
- As these languages are capable of executing procedures, the
specifications of this period define not only data structures,
- but also operations that apply to these structures.
- </p><p>
- Thereafter, enthusiasm for âWeb 2.0â increased interest for
<abbr>XML</abbr> over other languages.
- Older implementation specifications were deprecated,
- and <abbr title="XML Schema Definition">XSD</abbr> schemas became the
main concretization of abstract specifications.
- Even the way abstract specifications are designed has evolved: they
are less likely to define operations, and so what remains is closer to
descriptions of database schemas.
- Some operations that were defined in older standards now appear, in
another form, in web service specifications.
- Finally, the term âimplementation specificationâ has been
deprecated, to be subsumed under the term â<abbr>OGC</abbr> standard.â
- But despite their depreciation, <a
href="http://www.opengeospatial.org/standards/retired";>old implementation
specifications</a> remain useful to programs in Java, because:
- </p>
- <ul>
- <li>Their simpler models, applied to the same concepts, are helpful in
understanding new specifications.</li>
- <li>They sometimes define easy ways to perform common tasks, where the
newer specifications limit themselves to general cases.</li>
- <li>As operations are more often omitted from the newer
specifications, the old ones remain a useful supplement when defining
<abbr>API</abbr>s.</li>
- </ul>
- <p>
- The Apache <abbr>SIS</abbr> project is based on the most recent
specifications,
- drawing from the archives of the <abbr>OGC</abbr> to complete certain
abstract standards or make them more usable.
- Some old definitions are preserved as âconvenience methodsâ, not
always bringing new functionality, but facilitating the practical use of a
library.
- </p>
- </article>
+ <details>
+ <summary>More about âimplementation specificationsâ</summary>
+ <article id="implementation-standard">
+ <header>
+ <h1>Historical note</h1>
+ </header>
+ <p>
+ At the turn of the millennium, the abstract specifications were
explicitly concretized in <i>implementation specifications</i>.
+ The term âimplementationâ is used here in the sense of all types
of interfaces (Java or others) derived from
+ <abbr title="Unified Modeling Language">UML</abbr> diagrams, and not
implementations in the Java sense.
+ Such specifications existed for <abbr title="Structured Query
Language">SQL</abbr>,
+ <abbr title="Common Object Request Broker
Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr>,
and Java languages.
+ As these languages are capable of executing procedures, the
specifications of this period define not only data structures,
+ but also operations that apply to these structures.
+ </p><p>
+ Thereafter, enthusiasm for âWeb 2.0â increased interest for
<abbr>XML</abbr> over other languages.
+ Older implementation specifications were deprecated,
+ and <abbr title="XML Schema Definition">XSD</abbr> schemas became
the main concretization of abstract specifications.
+ Even the way abstract specifications are designed has evolved: they
are less likely to define operations, and so what remains is closer to
descriptions of database schemas.
+ Some operations that were defined in older standards now appear, in
another form, in web service specifications.
+ Finally, the term âimplementation specificationâ has been
deprecated, to be subsumed under the term â<abbr>OGC</abbr> standard.â
+ But despite their depreciation, <a
href="http://www.opengeospatial.org/docs/retired";>old implementation
specifications</a> remain useful to programs in Java, because:
+ </p>
+ <ul>
+ <li>Their simpler models, applied to the same concepts, are helpful
in understanding new specifications.</li>
+ <li>They sometimes define easy ways to perform common tasks, where
the newer specifications limit themselves to general cases.</li>
+ <li>As operations are more often omitted from the newer
specifications, the old ones remain a useful supplement when defining
<abbr>API</abbr>s.</li>
+ </ul>
+ <p>
+ The Apache <abbr>SIS</abbr> project is based on the most recent
specifications,
+ drawing from the archives of the <abbr>OGC</abbr> to complete
certain abstract standards or make them more usable.
+ Some old definitions are preserved as âconvenience methodsâ, not
always bringing new functionality, but facilitating the practical use of a
library.
+ </p>
+ </article>
+ </details>
<p>
The following table lists the main norms used by the project.
Many norms are published both as <abbr>ISO</abbr> standards and as
<abbr>OGC</abbr> standards,
and their corresponding names are listed next to one another in the
first two columns.
+ The âimplementation specificationsâ section lists specifications
that bring few new concepts compared to abstract specifications,
+ but detail how to represent those concepts in specific environments like
<abbr>XML</abbr> documents.
Standards that are deprecated but still partially used appear <s>struck
through</s>.
Finally, GeoAPI packages will be introduced in upcoming chapters.
</p>
Modified: sis/site/trunk/book/fr/introduction.html
URL:
http://svn.apache.org/viewvc/sis/site/trunk/book/fr/introduction.html?rev=1745526&r1=1745525&r2=1745526&view=diff
==============================================================================
--- sis/site/trunk/book/fr/introduction.html (original)
+++ sis/site/trunk/book/fr/introduction.html Wed May 25 18:10:58 2016
@@ -116,83 +116,86 @@
- <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>.
- Lâ<abbr>OGC</abbr> organise quatre réunions par années, chacune
dâune durée de cinq jours,
- hébergées par des organisations membres sponsorisant lâévénement
(compagnies, universités, centres de recherches, <i>etc.</i>).
- Le continent hôte alterne entre lâEurope et lâAmérique du Nord,
avec une présence croissante en Asie depuis 2011.
- Ces réunions reçoivent habituellement entre 50 et 100 participants
parmi les centaines de membres de lâ<abbr>OGC</abbr>.
- Certains participants sont présents à quasiment toutes les réunions
et constituent des piliers de lâorganisation.
- </p><p>
- Les réunions de lâ<abbr>OGC</abbr> offrent des opportunités
dâéchanges avec des membres dâhorizons diverses.
- La création dâun standard <abbr>OGC</abbr> commence par le
regroupement dâorganisations ou dâindividus constatant un intérêt commun
pour une problématique.
- Un groupe de travail est proposé sous lâappellation de <i>Domain
Working Group</i> (<abbr>DWG</abbr>) ou <i>Standard Working Group</i>
(<abbr>SWG</abbr>).
- Les <abbr>DWG</abbr> sont ouverts à tout membre de
lâ<abbr>OGC</abbr>,
- tandis que les <abbr>SWG</abbr> nécessitent de la part des
participants un engagement à ne pas entraver
- la diffusion du standard par des réclamations de propriétés
intellectuelles.
- </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>.
- 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>
+ <details>
+ <summary>Pour en savoir plus sur le processus de
standardisation</summary>
+ <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>.
+ Lâ<abbr>OGC</abbr> organise quatre réunions par années, chacune
dâune durée de cinq jours,
+ hébergées par des organisations membres sponsorisant
lâévénement (compagnies, universités, centres de recherches, <i>etc.</i>).
+ Le continent hôte alterne entre lâEurope et lâAmérique du
Nord, avec une présence croissante en Asie depuis 2011.
+ Ces réunions reçoivent habituellement entre 50 et 100 participants
parmi les centaines de membres de lâ<abbr>OGC</abbr>.
+ Certains participants sont présents à quasiment toutes les
réunions et constituent des piliers de lâorganisation.
+ </p><p>
+ Les réunions de lâ<abbr>OGC</abbr> offrent des opportunités
dâéchanges avec des membres dâhorizons diverses.
+ La création dâun standard <abbr>OGC</abbr> commence par le
regroupement dâorganisations ou dâindividus constatant un intérêt commun
pour une problématique.
+ Un groupe de travail est proposé sous lâappellation de <i>Domain
Working Group</i> (<abbr>DWG</abbr>) ou <i>Standard Working Group</i>
(<abbr>SWG</abbr>).
+ Les <abbr>DWG</abbr> sont ouverts à tout membre de
lâ<abbr>OGC</abbr>,
+ tandis que les <abbr>SWG</abbr> nécessitent de la part des
participants un engagement à ne pas entraver
+ la diffusion du standard par des réclamations de propriétés
intellectuelles.
+ </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>.
+ 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>
+ </details>
@@ -213,54 +216,60 @@
- <article id="implementation-standard">
- <header>
- <h1>Note historique</h1>
- </header>
- <p>
- Au tournant du millénaire, les spécifications abstraites étaient
explicitement concrétisées dans des <i>spécifications
dâimplémentations</i>.
- Le terme « implémentation » était ici à prendre au sens de tout
type dâinterfaces (Java ou autres) dérivées des diagrammes
- <abbr title="Unified Modeling Language">UML</abbr> â et non pas
dâimplémentations au sens du Java.
- Des telles spécifications existaient pour les langages <abbr
title="Structured Query Language">SQL</abbr>,
- <abbr title="Common Object Request Broker Architecture">CORBA</abbr>,
<abbr title="Component Object Model">COM</abbr> et Java.
- Ces langages étant capables dâexécuter des procédures, les
spécifications de cette époque définissaient
- non seulement des structures de données, mais aussi des opérations
sâappliquant sur ces structures.
- </p><p>
- Par la suite, lâengouement pour le « web 2.0 » a fait grimper
lâintérêt pour le <abbr>XML</abbr> au détriment des autres langages.
- Les anciennes spécifications dâimplémentations ont été
dépréciées, et les schémas <abbr title="XML Schema Definition">XSD</abbr>
- sont devenus la principale concrétisation des spécifications
abstraites.
- Même la façon de concevoir les spécifications abstraites a
évoluée: les opérations y sont plus rarement définies,
- par conséquence ce qui reste ressemble davantage à des descriptions
de schémas de base de données.
- Certaines opérations qui étaient définies dans les anciennes normes
apparaissent maintenant, sous une autre forme, dans les spécifications des
services web.
- Enfin le terme « spécification dâimplémentation » a été
abandonné, pour être englobé dans « standard <abbr title="Open Geospatial
Consortium">OGC</abbr> ».
- Mais malgré leur dépréciation, les <a
href="http://www.opengeospatial.org/standards/retired";>anciennes
spécifications dâimplémentations</a>
- restent utiles aux programmes en langage Java car:
- </p>
- <ul>
- <li>
- Leurs modèles plus simples, appliqués aux mêmes concepts, aident
à comprendre les nouvelles spécifications.
- </li>
- <li>
- Ils définissent parfois des façons simples dâeffectuer des
tâches courantes
- là où les nouvelles spécifications se limitent au cas général.
- </li>
- <li>
- Les opérations étant plus souvent omises dans les nouvelles
spécifications,
- les anciennes spécifications restent un complément utile pour
définir des <abbr>API</abbr>.
- </li>
- </ul>
- <p>
- Le projet Apache <abbr title="Spatial Information System">SIS</abbr>
se base sur les spécifications les plus récentes,
- tout en puisant dans les archives de lâ<abbr title="Open Geospatial
Consortium">OGC</abbr>
- pour compléter certains standards abstraits ou les rendre un peu plus
facile dâutilisation.
- Certaines anciennes définitions sont conservées comme « méthodes
de commodités »,
- nâapportant pas toujours de nouvelles fonctionnalités mais
facilitant lâusage pratique dâune bibliothèque.
- </p>
- </article>
+ <details>
+ <summary>Pour en savoir plus sur les « spécifications
dâimplémentation »</summary>
+ <article id="implementation-standard">
+ <header>
+ <h1>Note historique</h1>
+ </header>
+ <p>
+ Au tournant du millénaire, les spécifications abstraites étaient
explicitement concrétisées dans des <i>spécifications
dâimplémentations</i>.
+ Le terme « implémentation » était ici à prendre au sens de
tout type dâinterfaces (Java ou autres) dérivées des diagrammes
+ <abbr title="Unified Modeling Language">UML</abbr> â et non pas
dâimplémentations au sens du Java.
+ Des telles spécifications existaient pour les langages <abbr
title="Structured Query Language">SQL</abbr>,
+ <abbr title="Common Object Request Broker
Architecture">CORBA</abbr>, <abbr title="Component Object Model">COM</abbr> et
Java.
+ Ces langages étant capables dâexécuter des procédures, les
spécifications de cette époque définissaient
+ non seulement des structures de données, mais aussi des opérations
sâappliquant sur ces structures.
+ </p><p>
+ Par la suite, lâengouement pour le « web 2.0 » a fait grimper
lâintérêt pour le <abbr>XML</abbr> au détriment des autres langages.
+ Les anciennes spécifications dâimplémentations ont été
dépréciées, et les schémas <abbr title="XML Schema Definition">XSD</abbr>
+ sont devenus la principale concrétisation des spécifications
abstraites.
+ Même la façon de concevoir les spécifications abstraites a
évoluée: les opérations y sont plus rarement définies,
+ par conséquence ce qui reste ressemble davantage à des
descriptions de schémas de base de données.
+ Certaines opérations qui étaient définies dans les anciennes
normes apparaissent maintenant, sous une autre forme, dans les spécifications
des services web.
+ Enfin le terme « spécification dâimplémentation » a été
abandonné, pour être englobé dans « standard <abbr title="Open Geospatial
Consortium">OGC</abbr> ».
+ Mais malgré leur dépréciation, les <a
href="http://www.opengeospatial.org/docs/retired";>anciennes spécifications
dâimplémentation</a>
+ restent utiles aux programmes en langage Java car:
+ </p>
+ <ul>
+ <li>
+ Leurs modèles plus simples, appliqués aux mêmes concepts,
aident à comprendre les nouvelles spécifications.
+ </li>
+ <li>
+ Ils définissent parfois des façons simples dâeffectuer des
tâches courantes
+ là où les nouvelles spécifications se limitent au cas général.
+ </li>
+ <li>
+ Les opérations étant plus souvent omises dans les nouvelles
spécifications,
+ les anciennes spécifications restent un complément utile pour
définir des <abbr>API</abbr>.
+ </li>
+ </ul>
+ <p>
+ Le projet Apache <abbr title="Spatial Information System">SIS</abbr>
se base sur les spécifications les plus récentes,
+ tout en puisant dans les archives de lâ<abbr title="Open
Geospatial Consortium">OGC</abbr>
+ pour compléter certains standards abstraits ou les rendre un peu
plus facile dâutilisation.
+ Certaines anciennes définitions sont conservées comme «Â
méthodes de commodités »,
+ nâapportant pas toujours de nouvelles fonctionnalités mais
facilitant lâusage pratique dâune bibliothèque.
+ </p>
+ </article>
+ </details>
<p>
Le tableau suivant liste les principales normes utilisées par le projet.
Plusieurs normes sont publiées à la fois comme standard
<abbr>ISO</abbr> et comme standard <abbr>OGC</abbr>,
dâoù la disposition côte-à -côte des deux premières colonnes.
+ La section des « spécifications dâimplémentation » liste des
spécifications qui apportent peu de concepts nouveaux
+ comparativement aux spécifications abstraites, mais précisent comment
les représenter dans des contextes précis
+ tels quâun document <abbr>XML</abbr>.
Les normes dépréciées mais malgré tout partiellement utilisées
apparaissent <s>barrées</s>.
Enfin, les paquets GeoAPI seront introduits dans le chapitre suivant.
</p>
Modified: sis/site/trunk/content/book/book.css
URL:
http://svn.apache.org/viewvc/sis/site/trunk/content/book/book.css?rev=1745526&r1=1745525&r2=1745526&view=diff
==============================================================================
--- sis/site/trunk/content/book/book.css (original)
+++ sis/site/trunk/content/book/book.css Wed May 25 18:10:58 2016
@@ -95,6 +95,10 @@ p {
text-align: justify;
}
+summary:hover {
+ cursor: pointer;
+}
+
div.example {
margin-left: 21px;
margin-right: 24px;
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=1745526&r1=1745525&r2=1745526&view=diff
==============================================================================
--- sis/site/trunk/content/book/en/developer-guide.html (original)
+++ sis/site/trunk/content/book/en/developer-guide.html Wed May 25 18:10:58 2016
@@ -154,6 +154,8 @@ and <a href="http://en.wikipedia.org/wik
+<details>
+<summary>More about standardization process</summary>
<article id="OGC-process">
<header>
<h1><abbr>OGC</abbr> Standardization Process</h1>
@@ -224,6 +226,7 @@ Each proposal is reviewed by the <abbr t
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>
+</details>
<h3 id="SpecificationTypes"><span class="section-number">1.1.1.</span> Types
of Specifications</h3>
@@ -242,6 +245,8 @@ Certain data structures only exist in a
+<details>
+<summary>More about âimplementation specificationsâ</summary>
<article id="implementation-standard">
<header>
<h1>Historical note</h1>
@@ -261,7 +266,7 @@ and <abbr title="XML Schema Definition">
Even the way abstract specifications are designed has evolved: they are less
likely to define operations, and so what remains is closer to descriptions of
database schemas.
Some operations that were defined in older standards now appear, in another
form, in web service specifications.
Finally, the term âimplementation specificationâ has been deprecated, to
be subsumed under the term â<abbr title="Open Geospatial
Consortium">OGC</abbr> standard.â
-But despite their depreciation, <a
href="http://www.opengeospatial.org/standards/retired";>old implementation
specifications</a> remain useful to programs in Java, because:
+But despite their depreciation, <a
href="http://www.opengeospatial.org/docs/retired";>old implementation
specifications</a> remain useful to programs in Java, because:
</p>
<ul>
<li>Their simpler models, applied to the same concepts, are helpful in
understanding new specifications.</li>
@@ -274,10 +279,13 @@ drawing from the archives of the <abbr>O
Some old definitions are preserved as âconvenience methodsâ, not always
bringing new functionality, but facilitating the practical use of a library.
</p>
</article>
+</details>
<p>
The following table lists the main norms used by the project.
Many norms are published both as <abbr>ISO</abbr> standards and as
<abbr>OGC</abbr> standards,
and their corresponding names are listed next to one another in the first two
columns.
+The âimplementation specificationsâ section lists specifications that
bring few new concepts compared to abstract specifications,
+but detail how to represent those concepts in specific environments like
<abbr>XML</abbr> documents.
Standards that are deprecated but still partially used appear <s>struck
through</s>.
Finally, GeoAPI packages will be introduced in upcoming chapters.
</p>
@@ -289,157 +297,139 @@ Finally, GeoAPI packages will be introdu
<th>Titre</th>
<th>GeoAPI package</th>
<th>Apache SIS package</th>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Abstract Specifications</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19103</td>
<td/>
<td><i>Conceptual schema language</i></td>
<td><code class="GeoAPI">org.opengis.util</code></td>
<td><code class="SIS">org.apache.sis.util.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19115-1</td>
<td>Topic 11</td>
<td><i>Metadata</i></td>
<td><code class="GeoAPI">org.opengis.metadata</code></td>
<td><code class="SIS">org.apache.sis.metadata.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19115-2</td>
<td/>
<td><i>Metadata â extensions for imagery and gridded data</i></td>
<td><code class="GeoAPI">org.opengis.metadata</code></td>
<td><code class="SIS">org.apache.sis.metadata.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19111</td>
<td>Topic 2</td>
<td><i>Spatial referencing by coordinates</i></td>
<td><code class="GeoAPI">org.opengis.referencing</code></td>
<td><code class="SIS">org.apache.sis.referencing</code></td>
-</tr>
-<tr>
+</tr><tr>
+<td><abbr>ISO</abbr> 19111-2</td>
+<td/>
+<td><i>Referencing â extension for parametric values</i></td>
+<td><code class="GeoAPI">org.opengis.referencing</code></td>
+<td><code class="SIS">org.apache.sis.referencing</code></td>
+</tr><tr>
<td><abbr>ISO</abbr> 19108</td>
<td/>
<td><i>Temporal Schema</i></td>
<td><code class="GeoAPI">org.opengis.temporal</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19107</td>
<td>Topic 1</td>
<td><i>Feature geometry</i></td>
<td><code class="GeoAPI">org.opengis.geometry</code></td>
<td><code class="SIS">org.apache.sis.geometry</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19101</td>
<td>Topic 5</td>
<td><i>Features</i></td>
<td><code class="GeoAPI">org.opengis.feature</code></td>
<td><code class="SIS">org.apache.sis.feature</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19123</td>
<td>Topic 6</td>
<td><i>Schema for coverage geometry and functions</i></td>
<td><code class="GeoAPI">org.opengis.coverage</code></td>
<td><code class="SIS">org.apache.sis.coverage</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19156</td>
<td>Topic 20</td>
<td><i>Observations and measurements</i></td>
<td><code class="GeoAPI">org.opengis.observation</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Implementation Specifications</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19139</td>
<td/>
<td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
<td/>
<td><code class="SIS">org.apache.sis.xml</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19136</td>
<td>OGC 07-036</td>
<td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
<td/>
<td><code class="SIS">org.apache.sis.xml</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19162</td>
<td>OGC 12-063</td>
<td><i>Well-known text representation of coordinate reference systems</i></td>
<td/>
<td><code class="SIS">org.apache.sis.io.wkt</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 13249</td>
<td/>
<td><i><abbr>SQL</abbr> spatial</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><s><abbr>OGC</abbr> 01-009</s></td>
<td><s><i>Coordinate Transformation Services</i></s></td>
<td><code class="GeoAPI">org.opengis.referencing</code></td>
<td><code class="SIS">org.apache.sis.referencing</code></td>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><s><abbr>OGC</abbr> 01-004</s></td>
<td><s><i>Grid Coverage</i></s></td>
<td><code class="GeoAPI">org.opengis.coverage</code></td>
<td><code class="SIS">org.apache.sis.coverage</code></td>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SLD</abbr></td>
<td><i>Styled Layer Descriptor</i></td>
<td><code class="GeoAPI">org.opengis.style</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Web Services</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19128</td>
<td><abbr>WMS</abbr></td>
<td><i>Web Map Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WMTS</abbr></td>
<td><i>Web Map Tile Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19142</td>
<td><abbr>WFS</abbr></td>
<td><i>Web Feature Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WCS</abbr></td>
<td><i>Web Coverage Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WPS</abbr></td>
<td><i>Web Processing Service</i></td>
@@ -452,15 +442,13 @@ Finally, GeoAPI packages will be introdu
<td><i>Location Services</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SWE</abbr></td>
<td><i>Sensor Web Enablement</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SOS</abbr></td>
<td><i>Sensor Observation Service</i></td>
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=1745526&r1=1745525&r2=1745526&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] Wed May 25
18:10:58 2016
@@ -185,6 +185,8 @@ D’autres exemples de standards de fait
+<details>
+<summary>Pour en savoir plus sur le processus de standardisation</summary>
<article id="OGC-process">
<header>
<h1>Processus de standardisation à l’<abbr>OGC</abbr></h1>
@@ -262,6 +264,7 @@ Certains groupes de travail utilisent d�
hébergés en dehors des structures de l’<abbr>OGC</abbr>.
</p>
</article>
+</details>
@@ -282,6 +285,8 @@ Certaines structures de données n’exi
+<details>
+<summary>Pour en savoir plus sur les « spécifications d’implémentation
»</summary>
<article id="implementation-standard">
<header>
<h1>Note historique</h1>
@@ -302,7 +307,7 @@ Même la façon de concevoir les spécif
par conséquence ce qui reste ressemble davantage à des descriptions de schémas
de base de données.
Certaines opérations qui étaient définies dans les anciennes normes
apparaissent maintenant, sous une autre forme, dans les spécifications des
services web.
Enfin le terme « spécification d’implémentation » a été abandonné, pour être
englobé dans « standard <abbr title="Open Geospatial Consortium">OGC</abbr> ».
-Mais malgré leur dépréciation, les <a
href="http://www.opengeospatial.org/standards/retired";>anciennes spécifications
d’implémentations</a>
+Mais malgré leur dépréciation, les <a
href="http://www.opengeospatial.org/docs/retired";>anciennes spécifications
d’implémentation</a>
restent utiles aux programmes en langage Java car:
</p>
<ul>
@@ -326,10 +331,14 @@ Certaines anciennes définitions sont co
n’apportant pas toujours de nouvelles fonctionnalités mais facilitant l’usage
pratique d’une bibliothèque.
</p>
</article>
+</details>
<p>
Le tableau suivant liste les principales normes utilisées par le projet.
Plusieurs normes sont publiées à la fois comme standard <abbr
title="International Organization for Standardization">ISO</abbr> et comme
standard <abbr>OGC</abbr>,
d’où la disposition côte-à-côte des deux premières colonnes.
+La section des « spécifications d’implémentation » liste des spécifications
qui apportent peu de concepts nouveaux
+comparativement aux spécifications abstraites, mais précisent comment les
représenter dans des contextes précis
+tels qu’un document <abbr>XML</abbr>.
Les normes dépréciées mais malgré tout partiellement utilisées apparaissent
<s>barrées</s>.
Enfin, les paquets GeoAPI seront introduits dans le chapitre suivant.
</p>
@@ -341,178 +350,157 @@ Enfin, les paquets GeoAPI seront introdu
<th>Titre</th>
<th>Paquet de GeoAPI</th>
<th>Paquet de Apache SIS</th>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Spécifications abstraites</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19103</td>
<td/>
<td><i>Conceptual schema language</i></td>
<td><code class="GeoAPI">org.opengis.util</code></td>
<td><code class="SIS">org.apache.sis.util.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19115-1</td>
<td>Topic 11</td>
<td><i>Metadata</i></td>
<td><code class="GeoAPI">org.opengis.metadata</code></td>
<td><code class="SIS">org.apache.sis.metadata.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19115-2</td>
<td/>
<td><i>Metadata — extensions for imagery and gridded data</i></td>
<td><code class="GeoAPI">org.opengis.metadata</code></td>
<td><code class="SIS">org.apache.sis.metadata.iso</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19111</td>
<td>Topic 2</td>
<td><i>Spatial referencing by coordinates</i></td>
<td><code class="GeoAPI">org.opengis.referencing</code></td>
<td><code class="SIS">org.apache.sis.referencing</code></td>
-</tr>
-<tr>
+</tr><tr>
+<td><abbr>ISO</abbr> 19111-2</td>
+<td/>
+<td><i>Referencing — extension for parametric values</i></td>
+<td><code class="GeoAPI">org.opengis.referencing</code></td>
+<td><code class="SIS">org.apache.sis.referencing</code></td>
+</tr><tr>
<td><abbr>ISO</abbr> 19108</td>
<td/>
<td><i>Temporal Schema</i></td>
<td><code class="GeoAPI">org.opengis.temporal</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19107</td>
<td>Topic 1</td>
<td><i>Feature geometry</i></td>
<td><code class="GeoAPI">org.opengis.geometry</code></td>
<td><code class="SIS">org.apache.sis.geometry</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19101</td>
<td>Topic 5</td>
<td><i>Features</i></td>
<td><code class="GeoAPI">org.opengis.feature</code></td>
<td><code class="SIS">org.apache.sis.feature</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19123</td>
<td>Topic 6</td>
<td><i>Schema for coverage geometry and functions</i></td>
<td><code class="GeoAPI">org.opengis.coverage</code></td>
<td><code class="SIS">org.apache.sis.coverage</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19156</td>
<td>Topic 20</td>
<td><i>Observations and measurements</i></td>
<td><code class="GeoAPI">org.opengis.observation</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Spécifications d’implémentation</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19139</td>
<td/>
<td><i>Metadata <abbr>XML</abbr> schema implementation</i></td>
<td/>
<td><code class="SIS">org.apache.sis.xml</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19136</td>
<td>OGC 07-036</td>
<td><i>Geography Markup Language (<abbr>GML</abbr>) Encoding Standard</i></td>
<td/>
<td><code class="SIS">org.apache.sis.xml</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19162</td>
<td>OGC 12-063</td>
<td><i>Well-known text representation of coordinate reference systems</i></td>
<td/>
<td><code class="SIS">org.apache.sis.io.wkt</code></td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 13249</td>
<td/>
<td><i><abbr>SQL</abbr> spatial</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><s><abbr>OGC</abbr> 01-009</s></td>
<td><s><i>Coordinate Transformation Services</i></s></td>
<td><code class="GeoAPI">org.opengis.referencing</code></td>
<td><code class="SIS">org.apache.sis.referencing</code></td>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><s><abbr>OGC</abbr> 01-004</s></td>
<td><s><i>Grid Coverage</i></s></td>
<td><code class="GeoAPI">org.opengis.coverage</code></td>
<td><code class="SIS">org.apache.sis.coverage</code></td>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SLD</abbr></td>
<td><i>Styled Layer Descriptor</i></td>
<td><code class="GeoAPI">org.opengis.style</code></td>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td class="separator" colspan="5">Services web</td>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19128</td>
<td><abbr>WMS</abbr></td>
<td><i>Web Map Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WMTS</abbr></td>
<td><i>Web Map Tile Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td><abbr>ISO</abbr> 19142</td>
<td><abbr>WFS</abbr></td>
<td><i>Web Feature Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WCS</abbr></td>
<td><i>Web Coverage Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>WPS</abbr></td>
<td><i>Web Processing Service</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td>Open<abbr>LS</abbr></td>
<td><i>Location Services</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SWE</abbr></td>
<td><i>Sensor Web Enablement</i></td>
<td/>
<td/>
-</tr>
-<tr>
+</tr><tr>
<td/>
<td><abbr>SOS</abbr></td>
<td><i>Sensor Observation Service</i></td>
