Fonctionnalité #13332
Mis à jour par Cyril VAZQUEZ il y a environ 4 ans
En tant que SA, je veux utiliser un schéma de métadonnées descriptives étendu pour les unités d'archive afin de correspondre à des besoins du métier des services producteurs.
**Analyse**
Implique l'extension du schéma SEDA2 dans un nouvel espace de nom (ou en remplacement de l'espace de nom "officiel" ce qui ne serait pas la bonne pratique);
Deux options :
- intégrer un schéma custom pour les clients souhaitant étendre le SEDA 2 (donc lier le namespace du bordereau reçu à une config qui fournit le chemin du fichier xsd)
- utiliser une configuration pour étendre à la volée (runtime), un peu à la manière de manièr ede nos extension de profil d'archive (en modifiant la XSD DOM)
Dans les deux cas, étudier la pertinence et la valeur avant d’entamer des travaux plus complexes.
**Travaux réalisés**
Solution alternative :
- Proposer un schéma de paquet "SEDA 2.1 ouvert" qui ouvre la possibilité d'ajouter des balises "libres" à Content
- Si ajout au lieu de remplacement du schéma SEDA, ajouter de la configuration à "[medona] packageSchemas" pour indiquer le schéma à utiliser (chemin xsd en dur aujourd'hui pour SEDA 1 et 2)
Ensuite, 2 options :
- Traiter les champs complémentaires dans l'objet Content en mode "lax" (laxiste, oui) avec la dépendance xml : une balise est transformée
- en chaîne si arité 1 et aucun enfant
- en tableau si arité multiple
- en objet si elle contient des enfants
Problème: que fait-on sans schéma de métadonnées en entrée si certaines archives on une chaîne, d'autre un tableau de chaînes
- Traiter les champs complémentaires avec un schéma non xml (json, interne ?) afin d'avoir une description, nécessaire pour les accès aux métadonnées en consultation et modification.
**Analyse**
Implique l'extension du schéma SEDA2 dans un nouvel espace de nom (ou en remplacement de l'espace de nom "officiel" ce qui ne serait pas la bonne pratique);
Deux options :
- intégrer un schéma custom pour les clients souhaitant étendre le SEDA 2 (donc lier le namespace du bordereau reçu à une config qui fournit le chemin du fichier xsd)
- utiliser une configuration pour étendre à la volée (runtime), un peu à la manière de manièr ede nos extension de profil d'archive (en modifiant la XSD DOM)
Dans les deux cas, étudier la pertinence et la valeur avant d’entamer des travaux plus complexes.
**Travaux réalisés**
Solution alternative :
- Proposer un schéma de paquet "SEDA 2.1 ouvert" qui ouvre la possibilité d'ajouter des balises "libres" à Content
- Si ajout au lieu de remplacement du schéma SEDA, ajouter de la configuration à "[medona] packageSchemas" pour indiquer le schéma à utiliser (chemin xsd en dur aujourd'hui pour SEDA 1 et 2)
Ensuite, 2 options :
- Traiter les champs complémentaires dans l'objet Content en mode "lax" (laxiste, oui) avec la dépendance xml : une balise est transformée
- en chaîne si arité 1 et aucun enfant
- en tableau si arité multiple
- en objet si elle contient des enfants
Problème: que fait-on sans schéma de métadonnées en entrée si certaines archives on une chaîne, d'autre un tableau de chaînes
- Traiter les champs complémentaires avec un schéma non xml (json, interne ?) afin d'avoir une description, nécessaire pour les accès aux métadonnées en consultation et modification.