Projet

Général

Profil

Actions

Fonctionnalité #13332

fermé

Fonctionnalité #13326: [SEDA 2] Prise en compte des extensions

[SEDA 2] Gérer les métadonnées complémentaires dans content

Ajouté par Elodie SOME-BLAD il y a plus de 4 ans. Mis à jour il y a presque 3 ans.

Statut:
Rejeté
Priorité:
2-Sérieux
Assigné à:
Version cible:
Backlogs Produits - Inscription Backlog
Début:
26/02/2020
Echéance:
Tags RM:

Description

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, plusieurs 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 cardinalité 1 et aucun enfant
    • en tableau si cardinalité 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...

  • Traiter uniquement les champs complémentaires scalaires (chaîne, booléen, date, nombre) avec une cardinalité de 1, comme le socle pour les métadonnées utilisateur. Ensuite, le schéma de description des archives pourra "raccrocher" avec une correspondance exacte des noms

==> proposition sur branche feat/13332 de Maarch RM et archivesPubliques

Actions

Formats disponibles : Atom PDF