Forum

Le GedCom est-il périmé?

Vous devez vous connecter pour ouvrir une nouvelle discussion ou poster un message dans le forum.

5 contributions / 0 nouveau(x)
Dernière contribution
Portrait de yannig
#1
Portrait de Scribae
Merci pour ce message très instructif !
Portrait de Hervé BALESTRIERI
La "grammaire" du GEDCOM, c'est à dire son niveau sémantique, n'est certainement pas dépassée, car la science généalogique n'a pas fondamentalement évolué depuis que les Mormons, à la partir de la fin des années 1980, ont cherché à l'informatiser. Vous en rappelez beaucoup de ses possibilités, ce qui intéressera les lecteurs à même de plonger avec délices, comme vous le faites, dans les subtilités du codage et de l'emploi des multiples fonctions qu'il prend en charge. Vous dites que vous utilisez un logiciel qui respecte au pied de la lettre la norme GEDCOM. Pour ma part, j'attribue à certains éditeurs de logiciels un certain dédain, voire une paresse coupable dans leur support de la norme "de facto" d'échanges d'informations généalogiques, ce qui leur permet de "verrouiller" leur clientèle ayant patiemment rempli, et parfois sur des milliers de fiches, des champs d'informations qui ne pourront jamais sortir de leur logiciel car celui-ci "bride" l'export GEDCOM en omettant ces informations... Mais ceci n'est qu'une considération commerciale. Avant de développer les raisons qui, pour moi, doivent amener à réfléchir sur la pérennité du standard GEDCOM, je voudrais tout d'abord m'arrêter sur le point de la transmission des images : En effet, s'il n'est pas question de voir apparaître une image dans un fichier de format "texte brut", c'est méconnaître pour ce qui concerne la transmission un certain nombre des possibilités d'encodage de ce type d'informations, comme le font de nos jours les e-mails que nous nous échangeons en masse avec des photos jointes, car cet encodage pourrait très bien à mon sens s'intégrer au format GEDCOM : Il suffit que vous ayiez prévu à l'émission l'adaptation de cet encodage au format de la norme, ainsi que son décodage à la réception. Il faut préciser aussi que le format d'échange de données sous standard "XML" peut tout à fait prendre en charge la "grammaire" du standard GEDCOM, ainsi que, sous la condition développée plus haut, également la transmission d'images. Enfin, oui, GEDCOM est dépassé, et devrait être à plus moins long terme, remplacé par XML : Il n'est pas définitivement dépassé dans sa "grammaire", nous l'avons dit, il l'est surtout dans sa syntaxe, car celle-ci date d'une époque où les échanges s'effectuaient par des "fichiers plats", aux formats rigoureusement prédéfinis, et dont les programmes qui les "digéraient" avaient des possibilités d'interfacages très limitées. La richesse du format XML est sa faculté de pouvoir transmettre des données qui peuvent prendre une forme hiérarchique et potentiellement répétitive, tout en gardant la possibilité de définir un format rigoureux, pouvant correspondre à celui des Bases de données, si l'on adjoint le standard "XSD" qui convient pour ce faire. Un grand nombre d'applications s'appuient désormais sur ce format pour lire et échanger des données, comme par exemple, celles qui prennent désormais en charge la lecture de votre dossier médical numérisé. Ce n'est pas pour rien que les grands éditeurs de bases de données du marché, mais également celles qui sont parmi les plus populaires en logiciels libres prévoient que leurs moteurs de stockage et de recherche puissent gérer le format "XML" comme d'autres types de données plus élémentaires : chaînes de caractères, nombres... Mais, même en informatique, où l'on dit que les choses évoluent vite, les standards ou protocoles d'échanges ne meurent que si l'on ne s'en sert plus, ou bien si les avantages d'un autre protocole sont suffisamment "poussés en avant" par des éditeurs qui y trouvent un bénéfice. Le bénéfice pour les éditeurs de logiciels de généalogie est encore pour le moment du côté de la stabilité et de la perennité, car il ne raisonnent pas à l'échelle d'un marché "global", mais seulement "culturel", et très occidental. La voie du logiciel "libre" pousserait-elle les standards actuels comme XML dans le domaine de la généalogie, ce qui permettrait l'émergence de logiciels s'adaptant à toutes les cultures, en ouvrant les limites du standard "GEDCOM" ? C'est une possibilité à laquelle devraient réfléchir des éditeurs soucieux d'un "fond de commerce" encore plus large... Car les Mormons eux-mêmes ont préparé l'avenir avec la norme "GEDCOM X", et il serait aisé pour eux de répandre cette nouvelle norme en remplacement de celle qu'ils avaient forgée il y a près de 40 ans.
Portrait de yannig
Portrait de Jacques Joseph
Voilà quelques éléments qui complètent peut-être ce fil de discussion. J'ai essayé plusieurs logiciels qui permettent tous d'exporter une BD à la norme GEDCOM. Je me suis aussi formé à XML que j'ai utilisé pour la publication de dictionnaires. XML est un format très adapté à ce type de contenu simple et hiérarchisé. C'est un langage de balises (comme HTML mais en plus puissant) qui permet d'étiqueter les éléments d'information suivant la signification que lui affecte l'auteur (ou un groupe d'auteurs collaborant à distance) qui en l'occurrence créé son propre langage. D'une certaine manière la norme GEDCOM est aussi un langage assez proche de XML les balises en moins. Un fichier XML est un fichier texte, obéissant à quelques règles simples de balisage de l'information structurée qu'il contient, en cela il peut être considéré comme une base de données stricto sensu. Le grain élémentaire de la BD étant dans le cas présent l'individu, accompagné des tous ses éléments d'identification : nom, prénom,sexe, date et lieu de naissance, décés, relations verticales (parent/enfant) ou horizontale (conjoint, frêre, soeur etc.) Devant les limites des logiciels, j'ai converti ma BD GEDCOM en fichier XML, ce qui est assez facile avec un script php par exemple. La conversion inverse est aussi possible sans intermédiaire et encore plus facile avec un éditeur de texte comme NotePad++ par ex. Donc l'interopérabilité est acquise (réversibilité des fichiers). Bien sûr comme tout fichier texte et comme cela a été expliqué dans ce forum, il n'y a pas de possibilité d'intégrer des images à l'état natif. Mais la puissance du Web permet de stocker à part des images (y compris dans des supports distants) sans avoir à les transporter physiquement, les liens hypertextes se chargeant très bien d'assurer la liaison et la restitution des images le moment venu, ils constituent en cela l'essence même du Web. L'individu du fichier XML est représenté par un élément comprenant divers autres éléments (au sens de XML un élément est le texte compris entre deux balises ouvrantes de fermantes ex. ....) : Prénom NOM M jj mois aaaa lieu ... ...... Il est à noter que j'ai choisi de suivre au plus près la signification des éléments et des attributs GEDCOM, sans que cela soit obligatoire. Les noms des balises et des attributs reprennent au plus prés le nommage GEDCOM le fichier XML en reprennant la hiérarchie. On peut compléter à tout moment avec autant d'éléments que nécessaire et éventuellement en les imbriquant. Il est possible de séparer les individus, les familles, les sources etc. en divers fichiers indépendants voire distants, tout en conservant les liens entre éléments grâce aux attributs ID et IDREF. La BD comprend à peu près 1500 individus, le fichier contient 32 000 lignes. Le poids du fichier est de 500 Ko. Le temps d'une requête sur un nom est de quelques millisecondes, quelques secondes pour remonter un arbre sur 8 générations. Ceci pourrait être réduit en modifiant la structure de l'ensemble et les méthode de parcours des éléments de la BD. Le temps de chargement des images est lié à leur poids, mais en les limitant à quelques centaine de kO cela peut se gérer. Le langage XSLT (Extended Stylesheet Langage Transformation ) permet de manipuler les données du fichier XML et de les adpater au but rechercher en transformant les divers éléments en champs HTML et donc de les afficher sous la forme voulue, les feuilles de style CSS (Cascading Style Sheet) offrant toutes les possibilités de style (couleurs, boîtes etc.) Le langage XSLT permet entre autre de sélectionner des champs, de les trier, de sélectionner et d'afficher les fiches individuelles, la liste des enfants, le nom des parents, d'afficher tous les descendants d'un individu ou à l'inverse tous ses ascendants ou bien toutes les personnes ayant une structure identique, d'ajouter des images... Il est aussi possible d'interconnecter des fichiers distants ayant la même structure afin d'agrandir une base de données sans regroupement physique. Cela permet par exemple à plusieurs auteurs d'assembler des éléments familiaux épars et de compléter un arbre en utilisant le même schéma XSD ou la même DTD. Le peuplement de la BD se fait à la main avec un peu de rigueur, il serait aussi possible d'intégrer un formulaire de saisie en utilisant un script php par ex. Le couple XML-XSLT (avec un peu de javascript pour animer le tout) représente un avantage évident sur GEDCOM, car il permet l'affichage direct des données après filtage éventuel, sans passer par des transformations compliquées. Cela demande cependant un peu de formation et une pratique certaine. En conclusion ou peut affirmer que XML répond entièrement aux besoins de communication, d'échanges et d'interopérabilité y compris en matière de généalogie, ce que ne permet pas entièrement GEDCOM. Le choix entre GEDCOM ou XML n'est lié en fait qu'aux pratiques et aux usages d'échange entre commnautés. Pour l'insant GEDCOM reste incontournable, en formulant le voeux que dans un avenir proche XML prenne le relai.Il y a fort à parier que si XML avait été connu par les pères de GEDCOM c'est ce langage là qu'ils auraient choisi. Malheureusement les recommandations de la W3C en la matière ne datent que de 1998.