Chargement dynamique des namespaces dans le module XQuery de génération des registres
Contexte
La génération des registres resources_register.xml et fragments_register.xml est assurée par un module XQuery qui doit connaître statiquement, à la compilation, les namespaces des vocabulaires utilisés.
DoTS embarque nativement les namespaces de Dublin Core étendu et de schema.org. Tout autre vocabulaire référencé dans metadata/dots_metadata_mapping.xml provoque une erreur à la création du projet.
Problème
Le module XQuery de création des registres ne peut pas, en l'état, exploiter des namespaces qui ne lui ont pas été déclarés statiquement. Cela contraint l'utilisateur à se limiter aux vocabulaires supportés nativement par DoTS, ce qui va à l'encontre de l'objectif de généricité de l'outil.
La solution alternative actuelle consiste à déclarer statiquement dans le code de DoTS les namespaces utilisés, ce qui n'est pas une bonne pratique.
Proposition
Étudier la possibilité de charger dynamiquement, à partir de metadata/dots_metadata_mapping.xml, les déclarations de namespaces complémentaires nécessaires au module XQuery lors de la création du projet — sans avoir à modifier le code source de DoTS.
Le fichier dots_metadata_mapping.xml étant déjà la source de vérité pour la configuration des métadonnées, il constitue le point d'entrée naturel pour déclarer également les namespaces supplémentaires requis.
Piste de résolution : utilisation de fn:QName() et constructions dynamiques en XQuery
XQuery permet de manipuler des noms qualifiés de façon dynamique via fn:QName(uri, localname) ou la syntaxe de constructeur calculé element { fn:QName(...) } { ... }. Il serait ainsi possible de construire les éléments XML des registres sans déclarer les namespaces en dur, en les résolvant à l'exécution directement à partir du contenu de dots_metadata_mapping.xml.
Cette approche présente l'avantage de ne nécessiter aucune modification de la déclaration de module XQuery, ni aucune étape de pré-traitement externe. Elle peut toutefois complexifier la lisibilité du code XQuery existant.
Chargement dynamique des namespaces dans le module XQuery de génération des registres
Contexte
La génération des registres
resources_register.xmletfragments_register.xmlest assurée par un module XQuery qui doit connaître statiquement, à la compilation, les namespaces des vocabulaires utilisés.DoTS embarque nativement les namespaces de Dublin Core étendu et de
schema.org. Tout autre vocabulaire référencé dansmetadata/dots_metadata_mapping.xmlprovoque une erreur à la création du projet.Problème
Le module XQuery de création des registres ne peut pas, en l'état, exploiter des namespaces qui ne lui ont pas été déclarés statiquement. Cela contraint l'utilisateur à se limiter aux vocabulaires supportés nativement par DoTS, ce qui va à l'encontre de l'objectif de généricité de l'outil.
La solution alternative actuelle consiste à déclarer statiquement dans le code de DoTS les namespaces utilisés, ce qui n'est pas une bonne pratique.
Proposition
Étudier la possibilité de charger dynamiquement, à partir de
metadata/dots_metadata_mapping.xml, les déclarations de namespaces complémentaires nécessaires au module XQuery lors de la création du projet — sans avoir à modifier le code source de DoTS.Le fichier
dots_metadata_mapping.xmlétant déjà la source de vérité pour la configuration des métadonnées, il constitue le point d'entrée naturel pour déclarer également les namespaces supplémentaires requis.Piste de résolution : utilisation de
fn:QName()et constructions dynamiques en XQueryXQuery permet de manipuler des noms qualifiés de façon dynamique via
fn:QName(uri, localname)ou la syntaxe de constructeur calculéelement { fn:QName(...) } { ... }. Il serait ainsi possible de construire les éléments XML des registres sans déclarer les namespaces en dur, en les résolvant à l'exécution directement à partir du contenu dedots_metadata_mapping.xml.Cette approche présente l'avantage de ne nécessiter aucune modification de la déclaration de module XQuery, ni aucune étape de pré-traitement externe. Elle peut toutefois complexifier la lisibilité du code XQuery existant.