ISO 19118:2011

NORME ISO
INTERNATIONALE 19118
Deuxième édition
2011-10-15
Information géographique — Codage
Geographic information — Encoding

Numéro de référence
©
ISO 2011
DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO 2011
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2011 – Tous droits réservés

Sommaire Page
Avant-propos . iv
Introduction . v
1  Domaine d'application . 1
2  Conformité . 1
2.1  Introduction . 1
2.2  Classes de conformité relatives aux règles de codage . 1
2.3  Classes de conformité relatives aux services de codage . 1
3  Références normatives . 2
4  Termes et définitions . 2
5  Symboles et termes abrégés . 6
6  Concepts et hypothèses fondamentaux . 7
6.1  Concepts . 7
6.2  Échange de données . 7
6.3  Schéma d'application . 8
6.4  Règle de codage . 9
6.5  Service de codage . 10
6.6  Service de transfert . 11
7  Répertoire de caractères . 11
8  Modèle d'instance générique . 12
8.1  Introduction . 12
8.2  Rapport entre UML et modèle d'instance . 14
9  Règles de codage . 15
9.1  Introduction . 15
9.2  Exigences générales de codage . 16
9.3  Structure de données entrante . 18
9.4  Structure de données sortante . 18
9.5  Règles de conversion . 19
9.6  Exemples . 19
10  Service de codage . 19
Annexe A (normative) Règle de codage basée sur XML . 21
Annexe B (normative) Suite de tests abstraits . 22
Annexe C (informative) Règle de codage basée sur XML en usage par les communautés . 26
Bibliographie . 69

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 19118 a été élaborée par le comité technique ISO/TC 211, Information géographique/Géomatique.
Cette deuxième édition annule et remplace la première édition (ISO 19118:2005), qui a fait l'objet d'une
révision technique.
iv © ISO 2011 – Tous droits réservés

Introduction
La présente Norme internationale spécifie les exigences pour la définition des règles de codage utilisées dans
l'échange de données géographiques dans le cadre de l'ensemble de Normes internationales connu sous le
nom de «série ISO 19100». Une règle de codage permet de coder une information géographique définie par
des schémas d'application et des schémas normalisés dans une structure de données indépendante vis-à-vis
du système, adaptée au transport et au stockage. La règle de codage spécifie les types de données à
encoder, ainsi que la syntaxe, la structure et les méthodes de codage utilisées dans la structure de données
créée. La structure de données créée peut être conservée sur média numériques ou transférée à l'aide de
protocoles de transfert. Elle est destinée à la lecture et l'interprétation des données par voie informatique,
mais peut se présenter sous une forme lisible par l'homme.
Le choix d'une règle de codage destinée à l'échange de données indépendantes vis-à-vis de l'application
n'empêche pas les domaines d'application et les états individuels de définir et d'utiliser leurs propres règles de
codage pouvant être dépendantes d'une plateforme ou plus efficaces compte tenu de la taille des données ou
de la complexité de traitement. XML est un sous-ensemble de l'ISO/CEI 8879 et a été sélectionné parce qu'il
s'agit d'une plateforme informatique indépendante et compatible avec le réseau de l'Internet.
La présente Norme internationale se divise en trois sections logiques. Les exigences de création des règles
de codage se basant sur les schémas UML sont spécifiées aux Articles 6 à 9. Les exigences de création du
service de codage sont spécifiées à l'Article 10 et les exigences des règles de codage du langage XML sont
spécifiées à l'Annexe A.
La règle de codage XML est destinée à l'échange neutre de données. Elle se base sur le langage de balisage
extensible (XML, Extensible Markup Language) et les normes ISO/CEI 10646 relatives au jeu de caractères.
Les règles d'information géographique sont normalisées dans l'ensemble de Normes internationales connu
sous le nom de «série ISO 19100». Le contexte et la structure globale de cette série de Normes
internationales, ainsi que les techniques de description fondamentale sont définis dans l'ISO 19101,
l'ISO/TS 19103 et l'ISO/TS 19104.
Les utilisateurs de la présente Norme internationale peuvent développer des schémas d'application pour
décrire méthodiquement l'information géographique. Un schéma d'application est créé en intégrant des
éléments d'autres schémas conceptuels normalisés (par exemple l'ISO 19107). La façon de réaliser cette
intégration est décrite dans l'ISO 19109. L'ensemble de Normes internationales connu sous le nom de «série
ISO 19100» définit également un ensemble de services courants qui sont disponibles lorsqu'on développe
des applications d'information géographique. En général, ces services communs sont définis dans
l'ISO 19119 et concernent l'accès à l'information géographique et son traitement en fonction du modèle
d'information commun. La présente Norme internationale traite des questions de mise en œuvre.

NORME INTERNATIONALE ISO 19118:2011(F)

Information géographique — Codage
1 Domaine d'application
La présente Norme internationale spécifie les exigences pour la définition des règles de codage à utiliser pour
l'échange de données conformes à l'ensemble de Normes internationales relatives à l'information
géographique connu sous le nom de «série ISO 19100».
La présente Norme internationale spécifie
 les exigences de création des règles de codage basées sur les schémas UML,
 les exigences de création des services de codage, et
 les exigences en matière de règles de codage XML pour l'échange neutre de données.
La présente Norme internationale ne spécifie pas les média numériques, ne définit aucun service de transfert
ou de protocole de transfert, ni ne spécifie la façon d'encoder les grandes images en ligne.
2 Conformité
2.1 Introduction
Deux types de classes de conformité sont définis dans le cadre de la présente Norme internationale.
2.2 Classes de conformité relatives aux règles de codage
Toutes les règles de codage doivent passer tous les tests de la suite de tests abstraits en B.1. Toutes les
règles de codage doivent passer tous les tests de la suite de tests abstraits en B.2 et/ou B.3.
Tableau 1 — Classes de conformité relatives aux règles de codage
Classe de conformité Paragraphe de la suite de tests abstraits
Toutes les règles de codage B.1
Règle de codage avec conversion d'instance B.2
Règle de codage avec conversion de schéma B.3

2.3 Classes de conformité relatives aux services de codage
Tous les services de codage doivent passer tous les tests de la suite de tests abstraits en B.4. Selon les
capacités du service de codage, celui-ci doit passer tous les tests des classes de conformité supplémentaires,
conformément au Tableau 2.
Tableau 2 — Classes de conformité relatives aux services de codage
Classe de conformité Paragraphe de la suite de tests abstraits
Tous les services de codage B.4
Service de codage générique B.5
Service qui encode les données B.6
Service qui décode les données B.7
Service qui crée le schéma de structure de données sortante B.8

3 Références normatives
Les documents de référence suivants sont indispensables à l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 8601:2004, Éléments de données et formats d'échange — Échange d'information — Représentation de
la date et de l'heure
ISO/CEI 10646:2011, Technologies de l'information — Jeu universel de caractères codés (JUC)
ISO/TS 19103:2005, Information géographique — Langage de schéma conceptuel
ISO 19109:2005, Information géographique — Règles de schéma d'application
Langage de balisage extensible (XML) 1.0, Recommandation W3C. Disponible à
l'adresse http://www.w3.org/TR/REC-xml
4 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
4.1
schéma d'application
schéma conceptuel (4.5) des données (4.8) requises pour une ou plusieurs applications
[ISO 19101:2002, 4.2]
NOTE Le schéma d'application décrit le contenu, la structure et les contraintes applicables à l'information (4.22)
dans un domaine d'application spécifique.
4.2
caractère
composant d'un jeu d'éléments utilisé pour la représentation, l'organisation ou le contrôle des données (4.8)
[ISO/CEI 2382-1:1993, 01.02.11]
4.3
code
représentation d'un label conformément à une méthode spécifiée
2 © ISO 2011 – Tous droits réservés

4.4
modèle conceptuel
modèle (4.27) définissant les concepts de l'univers du discours (4.33)
[ISO 19101:2002, 4.4]
4.5
schéma conceptuel
description formelle d'un modèle conceptuel (4.4)
[ISO 19101:2002, 4.5]
4.6
langage de schéma conceptuel
langage formel basé sur un formalisme conceptuel destiné à représenter des schémas conceptuels (4.5)
[ISO 19101:2002, 4.6]
EXEMPLES UML, EXPRESS, IDEF1X.
NOTE Un langage de schéma conceptuel peut être lexical ou graphique.
4.7
règle de conversion
règle utilisée pour convertir les instances de la structure de données (4.8) entrante en instances de la
structure de données sortante
4.8
données
représentation réinterprétable d'une information (4.22) de façon formelle et adaptée à la communication, à
l'interprétation ou au traitement
[ISO/CEI 2382-1:1993, 01.01.02]
4.9
échange de données
livraison, réception et interprétation des données (4.8)
4.10
transfert de données
mouvement des données (4.8) d'un emplacement à un autre à l'aide d'un médium (4.26)
NOTE Le transfert d'informations (4.22) implique le transfert de données.
4.11
type de données
spécification d'un domaine de valeurs (4.34) et d'opérations autorisées sur les valeurs de ce domaine
[ISO/TS 19103:2005, 4.1.5]
EXEMPLES Integer (Nombre entier), Real (Réel), Boolean (Booléen), String (Chaîne) et Date (Date).
NOTE Le type de données est identifié par un terme, par exemple Integer. Les valeurs des types de données font
partie du domaine de valeurs spécifié, par exemple tous les nombres entiers entre –65537 et 65536. Les opérations
possibles sont +, -, * et / et sont sémantiquement bien définies. Un type de données peut être simple ou complexe. Un
type de données simple définit un domaine de valeurs où les valeurs sont considérées à l'unité dans un certain contexte,
par exemple Integer. Un type de données complexe est un regroupement de types de données. Un type de données
complexe peut représenter un objet et peut donc être identifiable.
4.12
jeu de données
ensemble identifiable de données (4.8)
[ISO 19115:2003, 4.2]
4.13
codage
conversion de données (4.8) en une série de codes (4.3)
4.14
règle de codage
ensemble identifiable de règles de conversion (4.7) qui définissent le codage (4.13) d'une structure de
données (4.8) spécifique
EXEMPLES XML, ISO 10303-21, ISO/CEI 8211.
NOTE La règle de codage spécifie les types de données à convertir, ainsi que la syntaxe, la structure et les
codes (4.3) utilisés dans la structure de données créée.
4.15
service de codage
composant logiciel implémentant une règle de codage (4.14)
4.16
entité
abstraction de phénomènes du monde réel
[ISO 19101:2002, 4.11]
NOTE Une entité peut se présenter comme un type ou une instance. Le type ou l'instance d'entité est utilisé
lorsqu'un seul d'entre eux est concerné.
4.17
fichier
ensemble nommé d'enregistrements conservés ou traités en tant qu'entité unitaire
[ISO/CEI 2382-1:1993, 01.08.06]
4.18
données géographiques
données (4.8) ayant une référence implicite ou explicite à une localisation relative à la Terre
[ISO 19109:2005, 4.12]
4.19
information géographique
information (4.22) concernant les phénomènes associés implicitement ou explicitement à une localisation
relative à la Terre
[ISO 19101:2002, 4.16]
4.20
identifiant
séquence de caractères (4.2) linguistiquement indépendante et capable d'identifier de manière exclusive et
permanente ce à quoi elle est associée
[ISO 19135:2005, 4.1.5]
4 © ISO 2011 – Tous droits réservés

4.21
convention d'identification
ensemble de règles servant à créer des identifiants (4.20)
4.22
information
connaissance relative aux objets, tels que les faits, évènements, choses, procédés ou idées, y compris les
concepts, qui a une signification particulière dans un certain contexte
[ISO/CEI 2382-1:1993, 01.01.01]
4.23
modèle d'instance
modèle (4.27) de représentation permettant de conserver les données (4.8) selon un schéma
d'application (4.1)
4.24
interface
UML ensemble nommé d'opérations qui caractérisent le comportement d'un élément
[ISO/CEI 19501]
4.25
interopérabilité
capacité de communiquer, d'exécuter des programmes ou de transférer des données (4.8) parmi diverses
unités fonctionnelles d'une façon n'exigeant de l'utilisateur que peu ou pas de connaissances des
caractéristiques spécifiques de ces unités
[ISO/CEI 2382-1:1993, 01.01.47]
4.26
médium
substance ou agence de stockage et de transmission des données (4.8)
[1]
EXEMPLES CD, Internet , ondes radio, etc.
4.27
modèle
abstraction de certains aspects de la réalité
[ISO 19109:2005, 4.14]
4.28
schéma
description formelle d'un modèle (4.27)
[ISO 19101:2002, 4.25]
4.29
modèle de schéma
modèle (4.27) de représentation destiné à conserver des schémas (4.28)
EXEMPLE Modèle de représentation destiné à un entrepôt de schéma.
4.30
stéréotype
UML nouveau type d'élément de modélisation qui étend la sémantique du métamodèle
[ISO/CEI 19501]
NOTE Il est nécessaire que les stéréotypes soient basés sur certains types ou classes existants dans le métamodèle.
Les stéréotypes peuvent étendre la sémantique, mais pas la structure des types et classes préexistants. Certains
stéréotypes sont prédéfinis dans l'UML, d'autres peuvent être définis par l'utilisateur. Les stéréotypes représentent l'un
des trois mécanismes d'extension du langage UML, les autres sont les contraintes et les valeurs d'étiquette.
4.31
protocole de transfert
ensemble commun de règles définissant les interactions entre systèmes distribués
4.32
unité de transfert
ensemble de données (4.8) destinées au transfert de données (4.10)
NOTE Une unité de transfert ne doit pas obligatoirement être identifiable, contrairement à un jeu de données (4.12).
4.33
univers du discours
vue du monde réel ou hypothétique incluant tout objet d'intérêt
[ISO 19101:2002, 4.29]
4.34
domaine de valeurs
ensemble de valeurs autorisées
[ISO/TS 19103:2005, 4.1.15]
EXEMPLES L'intervalle 3-28, tous les nombres entiers, tous les caractères, l'énumération de toutes les valeurs
autorisées (vert, bleu, blanc).
5 Symboles et termes abrégés
DCE Distributed computing environment (Environnement informatique distribué)
DUID Domain unique identifier (Identifiant unique de domaine)
HTML Hypertext markup language (Langage de balisage hypertexte)
MODIS Moderate resolution imaging spectroradiometer (Spectroradiomètre à image à résolution
modérée)
POSC Petroleum Open Standards Consortium (Consortium de normes ouvertes de l'industrie pétrolière)
TIFF Tagged image file format (Format de fichier image à balise)
UCS Universal multiple-octet coded character set [Jeu universel de caractères codés sur plusieurs
octets (JUC)]
UML Unified modeling language (Langage de modélisation unifié)
UTF UCS transfer format (Format de transfert pour UCS)
UUID Universally unique identifier (Identifiant unique universel)
XML Extensible markup language (Langage de balisage extensible)
6 © ISO 2011 – Tous droits réservés

6 Concepts et hypothèses fondamentaux
6.1 Concepts
L'objectif de l'ensemble de Normes internationales connu sous le nom de «série ISO 19100» est de permettre
l'interopérabilité entre les systèmes d'information géographique hétérogènes. Pour obtenir l'interopérabilité
entre les systèmes hétérogènes, il est nécessaire de déterminer deux éléments fondamentaux. En premier
lieu, il faut définir la sémantique du contenu et les structures logiques des données géographiques. Cela doit
être réalisé à l'aide d'un schéma d'application. Ensuite, il faut définir une structure de données indépendante
vis-à-vis de toute plateforme et de tout système qui puisse représenter les données correspondant au schéma
d'application.
Les concepts fondamentaux de l'échange de données, c'est-à-dire la procédure se basant sur le schéma
d'application pour coder, envoyer, recevoir et interpréter les données géographiques, sont décrits en 6.2 à 6.6.
Un aperçu du procédé d'échange de données est décrit en 6.2, 6.3 introduit des schémas d'application qui
permettent l'interprétation des données géographiques, 6.4 décrit l'importance de la règle de codage pour
produire des structures de données indépendantes vis-à-vis de tout système, 6.5 décrit un composant logiciel
appelé service de codage, qui exécute la règle de codage et 6.6 décrit la procédure d'envoi et de réception,
appelée service de transfert.
6.2 Échange de données
La Figure 1 montre un aperçu de l'échange des données. Le système A veut envoyer un jeu de données au
système B. Afin de garantir un échange réussi, il est nécessaire que A et B conviennent de trois points, c'est-
à-dire d'un schéma d'application commun I, de la règle de codage R à appliquer et du type de protocole de
transfert à utiliser. Le schéma d'application est la base d'un transfert de données réussi et définit le contenu et
la structure possibles des données transférées, alors que la règle de codage définit les règles de conversion
nécessaires pour déterminer la façon de coder les données dans une structure de données indépendante de
tout système.
Système A Système B
Schéma
d’application
Schéma Schéma
I
interne interne
A B
Base de
Base de
i i
M M
A B
AI IB
données données
interne
interne
Service de
Service de
codage
codage
(Décodage)
R
-1
R
d
d
Système Services
Services Système
de de
de de
Définit
fichiers transfert
transfert fichiers
Transfert de données
Flux de données
Limite du système Limite du système

Figure 1 — Aperçu de l'échange de données entre deux systèmes
Les deux systèmes, A et B, conservent les données dans une base de données interne en fonction d'un
schéma interne, mais les schémas sont généralement différents, c'est-à-dire que le schéma A n'est pas égal
au schéma B. Il est nécessaire de respecter les étapes logiques suivantes afin de transférer un jeu de
données de la base de données interne de A vers une base de données interne de B.
a) La première étape est de traduire les données internes du système A en une structure de données
conforme au schéma d'application commun I. Cela est possible en définissant une mise en
correspondance des concepts du schéma interne vers les concepts définis dans le schéma d'application
et en créant un logiciel approprié de mise en correspondance pour traduire les instances de données. À
la Figure 1, cette mise en correspondance est désignée par M . Il en résulte une structure de données
AI
spécifique i dérivée du schéma d'application. La structure de données est stockée dans une mémoire
A
ou dans un fichier intermédiaire et est dépendante du système et donc non adaptée au transfert.
b) L'étape suivante consiste à utiliser un service de codage, qui applique la règle de codage R pour créer
une structure de données indépendante du système et donc adaptée au transfert. Le jeu de données
encodé se nomme d et peut être conservé dans un système de fichiers ou transféré à l'aide d'un service
de transfert.
c) Le système A utilise ensuite un service de transfert pour envoyer le jeu de données d encodé vers le
système B. Le service de transfert suit un protocole de transfert pour déterminer le conditionnement et les
conditions de transport réel sur un médium de communication en ligne ou hors ligne. Il est nécessaire
que les deux parties conviennent du protocole de transfert utilisé.
d) Le service de transfert du système B reçoit le jeu de données transféré et, en fonction du protocole, le jeu
de données est décodé et sauvegardé comme un jeu de données d encodé, par exemple dans un fichier
intermédiaire.
e) Afin d'obtenir une structure de données spécifique i dérivée du schéma d'application, le système B
B
1
applique la règle de codage inverse R pour interpréter les données encodées.
f) Pour utiliser le jeu de données, il est nécessaire que B transpose la structure de données spécifique i
B
dérivée du schéma d'application dans sa base de données interne. Cela est possible en définissant une
mise en correspondance du schéma d'application vers son schéma interne et en créant un logiciel qui
effectue la transposition. À la Figure 1, cette mise en correspondance est désignée par M .
IB
La présente Norme internationale ne spécifie que les exigences de création des règles de codage et des
services de codage et non pas la totalité du procédé d'échange de données. Seules les étapes b) et e) sont
donc normalisées. Les étapes a), c), d) et f) ont recours aux services des technologies de l'information
d'usage général.
6.3 Schéma d'application
Un schéma d'application est un schéma conceptuel pour les applications ayant des exigences similaires
concernant les données. Le schéma d'application est la base d'un échange de données réussi et définit le
contenu et la structure possibles des données. C'est également la base pour l'implémentation de structures
de données propres au schéma d'application pour la sauvegarde locale des données.
Le schéma d'application utilisé pour encoder conformément à la présente Norme internationale doit être écrit
selon le langage du schéma conceptuel UML, conformément à l'ISO/TS 19103 et à l'ISO 19109. Ces Normes
internationales spécifient un cadre pour la création des schémas d'application. Ces règles comprennent des
spécifications relatives à l'utilisation de schémas normalisés pour la définition de types d'entités. Il est
nécessaire que le destinataire et l'expéditeur de données aient tous deux accès au schéma d'application.
Le schéma d'application doit être accessible aux deux parties de l'échange de données pour garantir un
résultat optimal. Il est nécessaire que le schéma d'application soit transféré avant la réalisation de l'échange
de données pour que l'expéditeur et le destinataire puissent préparer leurs systèmes en intégrant toutes les
mises en correspondance et toutes les structures de données conformément au schéma d'application. Il est
possible de le transférer avec le jeu de données ou de le sauvegarder dans un emplacement public, référencé
par le jeu de données.
Le schéma d'application peut s'échanger sur papier ou par le biais de méthodes électroniques.
8 © ISO 2011 – Tous droits réservés

6.4 Règle de codage
6.4.1 Concept
Une règle de codage est un ensemble identifiable de règles de conversion qui définit le codage d'une
structure de données particulière. La règle de codage spécifie le type de données à convertir, ainsi que la
syntaxe, la structure et les méthodes de codage utilisées dans la structure de données créée. Une règle de
codage est appliquée aux structures de données propres à un schéma d'application pour produire des
structures de données indépendantes du système et adaptées au transport et à la sauvegarde. Afin de définir
une règle de codage, il est nécessaire de spécifier trois éléments importants, à savoir la structure de données
entrante, la structure de données sortante et les règles de conversion entre les éléments des structures de
données entrante et sortante. Les structures de données entrante et sortante sont écrites sur la base d'un
langage de schéma conceptuel et les concepts de ce langage sont utilisés pour définir la règle de codage.
6.4.2 Structure de données entrante
La structure de données entrante est une structure de données spécifique du schéma d'application. La
structure de données peut être considérée comme un ensemble d'instances de données, c'est-à-dire
i = {i , ., i }; voir Figure 1. Chaque instance de données, i , est l'instance d'un concept I, défini dans un
1 p k l
schéma d'application. Le schéma d'application définit un ensemble de concepts définis dans le schéma
d'application I = {I , ., I }.
1 m
Le schéma d'application est un schéma conceptuel, c, écrit dans un langage de schéma conceptuel, C. Le
schéma conceptuel définit un ensemble de concepts c = {c , ., c } en instanciant les concepts du langage de
1 m
schéma conceptuel C = {C , ., C }. Puisque le schéma d'application est un schéma conceptuel, c = I.
1 r
6.4.3 Structure de données sortante
La structure de données sortante est définie par un schéma D = {D , ., D }. D est le schéma de la structure
1 s
sortante et n'est pas représenté à la Figure 1. La structure de données sortante peut être considérée comme
un ensemble d'instances de données, c'est-à-dire d = {d , ., d }, où chaque instance de données, d , est
1 q k
l'instance d'un concept, D .
l
Le schéma, D, définit la syntaxe, la structure et les méthodes de codage de la structure de données sortante.
6.4.4 Règles de conversion
Une règle de conversion spécifie la façon dont une instance de données dans la structure de données
entrante doit être convertie vers zéro, une, ou plusieurs instances dans la structure de données sortante. Les
règles de conversion sont définies et se basent sur les concepts du langage de schéma conceptuel, C, et sur
les concepts du schéma de structure de données sortante, D. Il est nécessaire de spécifier une règle de
conversion, R, pour chaque combinaison de concepts autorisée par le langage de schéma conceptuel.
i
L'ensemble de règles de conversion est donc R = {R , ., R }, où R est la ième règle de conversion et C est
1 n i i
la ième combinaison d'instances autorisée du langage de ce schéma. Il est possible d'établir une table de
conversion pour tous les C possibles, où chaque C conduit à la production d'instances dans la structure de
i i
données sortante, D. La Figure 2 montre les relations entre le langage de schémas conceptuels entrant et
sortant et la règle de codage.
Langage
Langage
de schéma
de
de structure
schéma
de données
conceptuel
sortantes
C
D
Règle de
Concepts Concepts
codage
entrants sortants
R
Figure 2 — La règle de codage définit les règles de conversion à partir
des concepts entrants jusqu'aux concepts sortants
NOTE Les règles de conversion se définissent sur la base des deux langages de schéma et non pas sur un schéma
d'application particulier. Cette approche générique permet aux développeurs de créer des services de codage
indépendants d'un schéma d'application, utilisables par différents schémas d'application à condition que les schémas
soient définis dans le même langage de schéma conceptuel.
6.5 Service de codage
Un service de codage est un composant logiciel qui permet d'exécuter la règle de codage et offre une
interface pour des fonctions de codage et de décodage. C'est un composant intégré à l'échange de données.
La Figure 3 présente en détail un service de codage et ses relations avec des schémas de spécification
importants. Le service de codage doit être en mesure de lire la structure de données entrante et de convertir
les instances vers une structure de données sortante et vice versa. Il doit également être en mesure de lire
les déclarations du schéma d'application et d'écrire le schéma correspondant de structure de données
sortante. La structure de données entrante est définie par un schéma d'application. Le schéma d'application
est défini à l'aide de concepts du langage de schéma conceptuel. La structure de données sortante est
également décrite par un schéma, appelé schéma de structure de données, qui définit le contenu, la structure
et les méthodes de codage possibles de la structure de données sortante. Le schéma de structure de
données est décrit par un langage de schéma. La règle de codage spécifie les règles de conversion à deux
niveaux: le premier au niveau du schéma et le second au niveau de l'instance. Au niveau du schéma, les
règles de conversion définissent une mise en correspondance de chaque concept défini dans le schéma
d'application aux concepts correspondants du schéma de la structure de données. Au niveau de l'instance,
les règles de conversion définissent une mise en correspondance de chaque instance de la structure de
données entrante aux instances correspondantes de la structure de données sortante. Les règles de
conversion d'instance sont en général issues des règles de conversion du schéma.
Schéma de
Schéma
structure de
Schéma
d’application
données
I
D
Service
de
codage
Instancesid
Entrée Sortie
Définit
Flux de données
Figure 3 — Aperçu du procédé de codage
10 © ISO 2011 – Tous droits réservés

Un service de codage doit au moins fournir les interfaces des fonctions de codage et de décodage. Des
exemples de ces interfaces sont pour le codage d = encode (i, I), et pour le décodage i = decode (d, I). Dans
ce cas, i est la référence à une structure de données spécifique du schéma d'application, I est la référence au
schéma d'application et d est la référence à la structure de données indépendante du système.
6.6 Service de transfert
Un service de transfert est un composant logiciel qui permet d'exécuter un ou plusieurs protocoles de transfert,
permettant le transfert de données entre systèmes d'information distribués sur un médium de communication
en ligne ou hors ligne. Pour transférer correctement les données entre deux systèmes, il est nécessaire que
l'expéditeur et le destinataire conviennent du protocole de transfert à utiliser.
Il est possible de définir plusieurs protocoles de transfert. Par exemple, dans les protocoles de transfert hors
ligne, les données sont sauvegardées sur un médium optique ou magnétique et envoyées par les services
postaux ou tout autre service de livraison spécifique. Dans le cas d'un protocole de transfert en ligne, les
données sont par exemple compressées et incluses sous la forme d'une pièce jointe dans un courrier
électronique, lequel est transmis à l'aide d'un protocole de transfert de fichier ou à l'aide d'un autre service
issu des technologies de l'information distribuée qui se base sur un service de réseau sous-jacent.
La présente Norme internationale ne prescrit aucun protocole de transfert spécifique.
7 Répertoire de caractères
L'ISO/CEI 10646 définit un répertoire de caractères reconnu sur le plan international, appelé Universal
Character Set (UCS) (jeu universel de caractères), ainsi que les méthodes de codage des caractères. Le jeu
de caractères normalisés définis au niveau international dans l'ISO/CEI 10646 doit être utilisé pour la mise en
œuvre de la présente Norme internationale.
Les méthodes de codage de caractères pouvant être supportées par les profils internationaux de la présente
Norme internationale sont les suivantes:
a) format de transfert pour UCS à taille variable à 8 bits, UTF-8;
b) format de transfert pour UCS à taille variable à 16 bits, UTF-16;
c) jeu universel de caractères à taille fixe à16 bits, UCS-2 (obsolète);
d) jeu universel de caractères à taille fixe à 32 bits, UCS-4.
Les règles internationales de codage qui se veulent en conformité avec la présente Norme internationale
doivent respecter une de ces méthodes de codage de caractères ou plusieurs d'entre elles. Dans le cadre de
profils nationaux et de mises en œuvre de systèmes, il est possible d'utiliser des méthodes de codage de
caractères différentes. Les méthodes de codage des caractères à taille fixe sont souvent utilisées dans la
mise en œuvre des bases de données et celles à taille variable sont souvent utilisées dans le cadre
d'échange de données.
L'ISO/CEI 10646 ne spécifie que le répertoire de caractères et ne fournit aucune indication quant au type de
langage réellement utilisé.
NOTE 1 Dans les cas où il est important de distinguer les différents langages de chaînes de texte, il est opportun
d'utiliser des mécanismes spéciaux afin d'indiquer le langage utilisé.
L'ISO/CEI 10646 définit les mécanismes de création des caractères composés. Les caractères composés
sont des caractères créés en superposant un ou plusieurs caractères additionnels sur un caractère de base.
L'ISO/CEI 10646 définit un ensemble de caractères précomposés et leur décomposition. Étant donné que
l'association des caractères composés et de leurs équivalents précomposés peut entraîner des problèmes
d'interprétation, l'utilisation d'un caractère composé est déconseillée si un caractère précomposé existe;
autrement dit, le caractère précomposé doit toujours être utilisé.
En résumé, une règle de codage doit
 supporter une ou plusieurs méthodes de codage des caractères;
 interdire l'utilisation de caractères composés si un caractère précomposé équivalent existe.
EXEMPLE Le caractère précomposé ö présente la décomposition définie par o¨.
NOTE 2 Pour obtenir une description plus détaillée de la normalisation des caractères, se référer
à http://www.unicode.org/reports/tr15/ et http://www.w3.org/TR/charmod-norm/.
NOTE 3 UTF-16, UCS-2 et UCS-4 exigent des informations relatives à la façon de traiter l'ordre des octets. Se référer
à http://www.unicode.org/faq/utf_bom.html.
8 Modèle d'instance générique
8.1 Introduction
L'Article 8 définit le modèle d'instance générique. Le modèle d'instance est une représentation commune et
adaptée des données lorsqu'on développe un service de codage. Le modèle d'instance est en mesure de
représenter les données décrites dans un schéma d'application exprimé en UML. Le modèle d'instance
représente la structure de données spécifique du schéma d'application définie à l'Article 6 (structures de
données i et i à la Figure 1). Le modèle d'instance est constitué d'un jeu de données (IM_Dataset) qui
A B
contient une séquence d'objets (IM_Object), où un objet se compose d'une séquence de propriétés
(IM_Property). Les propriétés dans ce contexte sont soit des attributs, soit des associations. Les opérations
ne sont pas incluses dans le modèle d'instance général. Chaque propriété est encodée en fonction de son
type de données. Le modèle d'instance est présenté à la Figure 4 et à la Figure 5.
Le schéma d'application définit un nombre de classes ainsi que leurs attributs et associations et représente la
base de création des représentations de données. Une représentation de données (jeu de données) contient
un ou plusieurs objets structurés et encodés en fonction de leur définition de classe. L'Article 8 décrit les
principes de représentation des objets, leurs attributs et les associations entre objets.
L'unité de base de l'information dans un jeu de données est l'objet. L'objet doit être l'instance d'une seule
classe concrète. Il n'existe pas d'instances de classes abstraites et de classes stéréotypées en interface. Les
propriétés définies par ces classes sont donc encodées en tant qu'éléments des classes concrètes dont elles
font partie ou qu'elles exécutent. Chaque classe doit avoir un nom unique dans le schéma d'application. Le
schéma d'application peut se référer à des classes définies dans les schémas normalisés ou dans d'autres
schémas d'application, ou les utiliser. La déclaration de ces classes doit soit être incluse dans le modèle UML
qui contient le schéma d'application, soit accompagner le schéma d'application dans un fichier distinct.
Un objet doit contenir un ensemble de valeurs de propriétés. La classe d'objet définit les propriétés, qui
peuvent soit être héritées des supertypes de la classe, soit être définies dans la classe elle-même. Afin de
différencier les propriétés, celles-ci doivent avoir un nom unique au sein de leur classe. Le type de données
de la propriété régit les valeurs possibles et la déclaration de multiplicité indique le nombre d'instances de
l'attribut dans un objet instancié.
Un objet possède une classe correspondante, définie dans un schéma d'application ou un schéma normalisé,
qui détermine les attributs et associations possibles nécessaires à la représentation de l'état de l'objet. Un
IM_Object se réfère à sa classe par l'attribut de «classe»; il doit être identifié dans le contexte d'un jeu de
données par son identifiant unique «id» et peut être identifié de façon universelle et unique dans un univers
défini, un domaine d'application ou un espace de noms par son attribut «duid».
12 © ISO 2011 – Tous droits réservés

<>
<>
Instance Model::IM_Object
Instance Model::IM_DataSet
object
+ id: CharacterString
+ id: CharacterString
+ duid: CharacterString
0.* 0.*
+ duid: CharacterString
+ /uuid: CharacterString
+ /uuid: CharacterString
+ type: GenericName
constraints
constraints
{uuid = duid}
{uuid = duid}
property 0.*
<>
Instance Model::IM_Property
+ name: GenericName
+ value: IM_Value [0.*] {ordered}

Figure 4 — Modèle d'instance — Jeu de données, objet et propriété
Les attributs définis par la classe et les extrémités des associations navigables depuis la classe sont mis en
correspondance dans un ensemble de propriétés. Une propriété (IM_Property) représente un nom et un
ensemble ordonné de valeurs. Elle peut représenter un attribut ou l'extrémité d'une association. Le nom de
propriété doit correspondre au nom d'attribut ou au nom de rôle cible d'une association. Une valeur
(IM_Value) représente une valeur de propriété.
Les valeurs nulles peuvent être fournies de façon explicite ou implicite. Une valeur nulle explicite doit être
indiquée par l'instance de l'IM_Property correspondante avec une valeur nilReason donnée. Une valeur nulle
implicite est indiquée si l'instance IM_Property correspondante est manquante.
<>
Instance M
...