Fonctionnalité #13332
Mis à jour par Cyril VAZQUEZ il y a plus de 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 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. Problème: il s'agit d'ajouter des propriétés à un objet existant (Content), pas de décrire un nouvel objet, donc l'extension passe forcément par une classe "Content" étendue aussi...