doc/profils.rst
author Sylvain Thénault <sylvain.thenault@logilab.fr>
Fri, 03 Nov 2017 08:14:05 +0100
changeset 2821 aad582bae5c8
parent 2791 4b7d28df3c52
child 2814 8804af520542
child 2816 84947b74ef67
permissions -rw-r--r--
[profile generation] Use standard xml:id instead of seda:profid In later commit we will insert identifiers using xml:id on more node. It sounds like there are no benefit in using a custom attribute, so uniformize toward using xml:id everywhere. Related to extranet #39304385

Export des profils SEDA
=======================

Selon leurs caractéristiques, les profils créés dans l'application sont exportable dans une ou
plusieurs versions du SEDA_ (2, 1 ou 0.2) au format RelaxNG_, celui-ci étant plus adapté à la
génération de profil que les `schémas XML`_.

Les versions supportées sont indiquées dans l'onglet 'diagnostique' du transfer.

Il est important de noter que quelque soit la version utilisée, le profil seul n'est pas suffisant
pour valider un bordereau. Il faut également valider ce dernier contre le schéma XSD de la version
correspondante, car elle permet de valider certains aspects qui ne seront pas validés par le profil.

Les profils autorisants plusieurs éléments de même nom à un même niveau avec
plus d'un d'entre eux ayant une cardinalité différente de 1 vont générer des
schémas RNG valide mais invérifiables par les validateurs existants. Une
solution technique reste à trouver pour ce problème.


.. _SEDA: https://redirect.francearchives.fr/seda/
.. _RelaxNG: http://relaxng.org/
.. _`schémas XML`: https://www.w3.org/XML/Schema


Export SEDA 2
-------------

Gestion des identifiants et références
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Les identifiants spécifiés dans l'interface utilisateur sur les objets-données et les unités
d'archives sont reportés via un attribut `xml:id` sur l'élément correspond dans le profil
RelaxNG_ généré ([1]_). La valeur de cette attribut est ensuite utilisée comme valeur par défaut des
éléments référençant cet élément.

Ce mécanisme permet de gérer des identifiants pour des éléments XSD qui ne sont
pas encore créés (puisqu'ils le seront à la création du bordereau), ce qui est
nécessaire pour pouvoir ensuite les référencer, la norme SEDA 2 faisant
largement usage de telles références. Il est à noter qu'il est donc à la
responsabilité de l'outil qui génère le bordereau de gérer les définitions de
références ainsi créées en substituant dans les éléments référencés la valeur de
l'identifiant qu'il a attribué à l'élément portant le `xml:id`
correspondant.

Ceci n'étant pas un mécanisme standard de RelaxNG_, la cohérence des références entre
le bordereau et le profil ne sera pas vérifiée par les outils de validation XSD
classiques.


.. [1] le préfix `seda` étant associé à l'espace de nom
   "fr:gouv:culture:archivesdefrance:seda:v2.0"

Autres limitations
~~~~~~~~~~~~~~~~~~

Il est à noter que les références sont exporté en utilisant le type `NCName` et non `IDREF` comme
dans le schéma XSD : c'est lié au fait qu'il n'est pas autorisé en RelaxNG_ d'utiliser le type
`IDREF` pour le contenu texte d'une balise, mais uniquement pour le contenu d'un attribut : ::

  <reference>id référencé</reference>

vs : ::

  <reference idref="id référencé"/>


Export SEDA 0.2 et 1
--------------------

Les schémas des versions 0.2 et 1 de la norme SEDA utilisent des types personnalisés venant de
différents espaces de nom (par exemple
`fr:gouv:culture:archivesdefrance:seda:v1.0:QualifiedDataType:1`,
`urn:un:unece:uncefact:data:standard:UnqualifiedDataType:10`, etc.). Ces types ne sont
malheureusement pas utilisables dans un schéma RelaxNG, uniquement XSD. Pour palier à ce problème,
les éléments utilisant ces types sont exportés en tant que simple chaîne de caractères "xsd:string",
en supposant que les transferts seront validés contre le profil *et* contre le schéma XSD de la
norme. La même stratégie était utilisée par Agape V1.

Le SEDA 2 n'utilise plus ces types et n'est donc pas exposé à ce problème.