Tag GEDCOM standard
SCHMA
Schéma d’extensions
Schema
Structure sous HEAD qui associe des tags d’extension documentés à des URI définissant leur sens.
Exemple concret
Exemple minimal
0 HEAD
1 GEDC
2 VERS 7.0
1 SCHMA
2 TAG _EXEMPLE https://example.org/terms/example
0 TRLR
Exemple réaliste
0 HEAD
1 GEDC
2 VERS 7.0
1 SCHMA
2 TAG _EXEMPLE https://example.org/terms/example
2 TAG _DOSSIER https://example.org/terms/dossier
0 @I1@ INDI
1 _EXEMPLE Valeur documentée
1 _DOSSIER D-42
0 TRLR
Traduction en langage humain
SCHMA déclare comment comprendre les tags d’extension documentés employés dans ce dataset ; les données restent dans leurs lignes _EXEMPLE ou _DOSSIER.
SCHMA déclare comment comprendre les tags d’extension documentés employés dans ce dataset ; les données restent dans leurs lignes _EXEMPLE ou _DOSSIER.
Explication pas à pas
L’objectif n’est pas seulement de reconnaître le tag, mais de comprendre ce qu’il fait à cet endroit précis de la hiérarchie.
1
Exemple minimal — « 0 HEAD » : le niveau 0 place HEAD sous le dataset.
2
Exemple minimal — « 1 GEDC » : le niveau 1 place GEDC sous HEAD.
3
Exemple minimal — « 2 VERS 7.0 » : le niveau 2 place VERS sous GEDC avec la valeur « 7.0 ».
4
Exemple minimal — « 1 SCHMA » : le niveau 1 place SCHMA sous HEAD.
5
Exemple minimal — « 2 TAG _EXEMPLE https://example.org/terms/example » : le niveau 2 place TAG sous SCHMA avec la valeur « _EXEMPLE https://example.org/terms/example ».
6
Exemple minimal — « 0 TRLR » : le niveau 0 place TRLR sous le dataset.
7
Exemple réaliste — « 0 HEAD » : le niveau 0 place HEAD sous le dataset.
8
Exemple réaliste — « 1 GEDC » : le niveau 1 place GEDC sous HEAD.
9
Exemple réaliste — « 2 VERS 7.0 » : le niveau 2 place VERS sous GEDC avec la valeur « 7.0 ».
10
Exemple réaliste — « 1 SCHMA » : le niveau 1 place SCHMA sous HEAD.
11
Exemple réaliste — « 2 TAG _EXEMPLE https://example.org/terms/example » : le niveau 2 place TAG sous SCHMA avec la valeur « _EXEMPLE https://example.org/terms/example ».
12
Exemple réaliste — « 2 TAG _DOSSIER https://example.org/terms/dossier » : le niveau 2 place TAG sous SCHMA avec la valeur « _DOSSIER https://example.org/terms/dossier ».
13
Exemple réaliste — « 0 @I1@ INDI » : le niveau 0 crée le record identifié par @I1@.
14
Exemple réaliste — « 1 _EXEMPLE Valeur documentée » : le niveau 1 place _EXEMPLE sous INDI avec la valeur « Valeur documentée ».
15
Exemple réaliste — « 1 _DOSSIER D-42 » : le niveau 1 place _DOSSIER sous INDI avec la valeur « D-42 ».
16
Exemple réaliste — « 0 TRLR » : le niveau 0 place TRLR sous le dataset.
17
SCHMA est un conteneur facultatif sous HEAD, sans payload.
18
Chaque TAG associe un tag commençant par underscore à l’URI qui identifie son concept.
19
SCHMA ne contient pas les valeurs des extensions : il fournit leur dictionnaire local.
20
Un SCHMA vide est syntaxiquement inutile ; TAG est répétable et devrait couvrir les extensions documentées utilisées.
21
Évolution attestée — SCHMA/TAG est le mécanisme GEDCOM 7 destiné à améliorer l’interopérabilité des extensions, absent du header FamilySearch GEDCOM 5.5.1.
22
Les tags d’extension commencent par un underscore.
23
Pour une extension documentée, le sens vient de l’URI et pas seulement du nom du tag.
24
Le schéma devrait apparaître avant l’utilisation des extensions.
Piège fréquent
À ne pas faire / à ne pas déduire :
Placer directement les données d’extension dans SCHMA au lieu de déclarer leur sens.
Placer directement les données d’extension dans SCHMA au lieu de déclarer leur sens.
Types de structure identifiés par SCHMA
Un même tag peut représenter plusieurs types de structures. La combinaison du tag et du type de sa structure parente détermine le type exact.
| Nom officiel | URI de type | Page |
|---|---|---|
| Extension schema | g7:SCHMA | 87 |
Urig7:SCHMA
ParentHEAD
PayloadAucun
CardinalityHEAD.SCHMA {0:1} ; SCHMA.TAG {0:M}