Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

XML permet d'étendre voir de concevoir entièrement des langages (applications) XML. En respectant les espaces de noms, on peut ainsi arriver à rester complètement compatible avec un langage donné tout en ajoutant des éléments et attributs propres.

Icon

Attention, ajouter des éléments et attributs propres à un schéma XML n'est pas anodin : cela revient finalement à définir un nouveau schéma XML ou plutôt une nouvelle application XML.
Dans le contexte de partages, d'échanges via des réseaux de portails communicant, cela doit se faire au maximum conjointement avec le plus de partenaires possibles et en utilisant au mieux des éléments/attributs déjà standardisés. En fait dans la majorité des cas, il faudra tenter de se contenter des éléments/attributs disponibles dans le schéma standard utilisé.
Ici on décrit techniquement les manipulations qui peuvent permettre d'ajouter des éléments et attributs dans un formulaire donné ... mais cela présuppose qu'une étude et une réflexion poussée ont été réalisées en amont. On peut alors procéder à ces manipulations en tout connaissance de cause ...
L'exemple donné ci-dessous se justifie comme ceci : on précise que l'on souhaite ajouter une métdonnée de gestion interne permettant de cibler l'UNT cible - l'idée étant finalement de créer des Sets OAI-PMH fonction des UNT, on répartit les fiches dans ces Sets en fonction du public cible (de cette nouvelle métadonnée).
On notera cependant pour être complet que, avec une réflexion plus poussée, l'utilisation d'une classification disciplinaire (type Dewey) devrait nous permettre de cibler l'UNT (ou les UNT) cible(s) d'une ressource donnée, et cela de manière plus élégante (car sans ajouter de spécificités internes aux applications XML que sont les LOM/LOMFR/SupLOMFR).

Enfin, à terme (à terme car c'est en cours de construction !) et pour un certain nombre de cas d'utilisation, l'idée ne sera pas d'étendre un schéma donné standard mais plutôt de proposer une description d'une même ressource via plusieurs applications XML, c'est la notion que l'on a appelée "format englobant" dans les échanges fonctionnels ORI-OAI et que l'on est en train de mettre en place actuellement. L'intérêt est alors de pouvoir présenter par exemple une fonctionnalité de screenshots via une application XML donné cela aussi bien pour les ressources dont les fiches sont locales ou moissonnées et qui sont déjà décrites en OAI_DC ou LOM ... on arrive alors finalement à plusieurs applications XML décrivant, par des points de vue fonctionnels différents, une même ressource.

Pour plus d'informations la dessus, revoyez également XmL et les Espaces de noms  sur ce même site.

Ici, on montre comment on peut ajouter une métadonnée à un XML LOM dans un espace de noms propre et comment on peut ensuite proposer à l'utilisateur d'éditer ce XML dans le formulaire LOM de l'éditeur de métadonnées ORI-OAI : ORI-OAI-MD-EDITOR.

En bref, ce chapitre explique comment on peut étendre/modifier (et en fait créer) un formulaire dans ORI-OAI-md-editor basé, on le rappelle, sur Orbeon Forms.

Espace de noms Rennes1 et exemple d'XML LOM Rennes1

Sur un ori-oai-md-editor d'installé et qui fonctionne, on va donc ici montrer comment créer un nouveau formulaire sur la base du formulaire LOM pour lui ajouter une nouvelle métadonnée.

Ici on se place dans la position de l'Université de Rennes1 par exemple qui veut rajouter une métadonnée interne pour "taguer" ses ressources : l'Université faisant partie de chacune des UNT, on souhaiterait en effet lors de l'indexation d'une ressource pédagogique préciser à quel UNT la ressource peut correspondre. Cela permet de cibler un certain public ... pour rester souple, on utilisera plutôt un nom de balise comme targetPublic par exemple.

Voici un exemple de fichier XML LOM étendu via un espace de noms et des balises propres à Rennes1 que l'on souhaiterait éditer dans notre nouveau formulaire donc :

Ce fichier est valide lomLoose, et on n'a pas forcément besoin de créer un schéma spécifique "LOM-Rennes1" pour notre besoin : celui-ci reste interne, notre espace de noms n'a pas vocation à être utilisé en dehors de nos applications. Par contre, on distingue bien grâce aux espaces de noms le LOM de nos balises personnelles.

Grâce aux espaces de noms, on peut noter que les différents modules peuvent travailler avec cet XML d'exemple ci-dessus : l'éditeur ori-oai-md-editor peut éditer cet XML directement (aussi bien la version complète, que la version auteur). Cependant, il ne nous permet pas d'éditer la partie spécifique Rennes1 qu'il ne connait pas.

C'est pourquoi on va réaliser un nouveau formulaire basé sur le formulaire LOM complet d'ori-oai-md-editor.

Formulaire LOM Rennes1

copier/coller

Confère la documentation du ori-oai-md-editor, le répertoire spécifique à ori-oai-md-editor dans l'application Orbeon Forms est : WEB-INF/resources/forms/ori-md-editor.
On va dupliquer le formulaire lom-full et l'appeler lom-full-extend  :

[ori-md-editor]$ cp -rf lom-full lom-full-extend

Les formulaires en tant que tels correspondent aux sous-répertoires du répertoire lom-full-extend .

Les fichiers d'initialisation des formulaires en mode "standalone" (non connecté au workflow) sont les fichiers du répertoire blank .

Dès maintenant et sans redémarrer votre serveur ori-oai-md-editor, vous devez pouvoir utiliser ce nouveau formulaire directement :

svn update

Pour ceux qui sont connectés via subversion (cf. l'Annexe B : « Exploitation d'applications avec subversion - installation et mises à jour », on vous encourage vivement à procéder de la sorte) vous pouvez garder le répertoire .svn copié au passage dans lom-full-extend, cela vous permet de continuer à vous synchroniser au répertoire lom-full du repository svn officiel de ori-oai-md-editor. Par contre pour ce faire vous devrez aller dans le répertoire lom-full-extend et faire un svn update indépendamment du svn update de l'ensemble :

a

svn update

U case-educational.xml

Uform.xhtml

Updated to revision nnn.

Prototype

Dans XForms et Orbeon Forms, l'ajout de noeud via un bouton "Ajouter un targetPublic" correspond en fait à un copier coller d'un nœud existant "ailleurs". Le "ailleurs" peut correspondre à une autre instance XML que celle que l'on édite. On appelle cela dans ori-oai-md-editor un prototype.

Ici, on va ajouter un prototype pour le LOM Rennes1 :

cd lom-full-extend/prototype
cp lom-prototype.xml lom-rennes1-prototype.xml

On y ajoute les tags vides qui vont bien, en n'oubliant pas de déclarer l'espace de noms :

Modification du formulaire

On se place dans le formulaire nouvellement créé pour maintenant le modifier :

cd lom-full-extend/form
ls

case-annotation.xml      case-general.xml       case-relation.xml   dialog-dewey-search.xml         dialog-vcard-person-search.xml  form.xhtmlcase-classification.xml  case-lifecycle.xml     case-rights.xml     dialog-taxonomy-search.xml      dialog-vcard-search.xmlcase-educational.xml     case-metametadata.xml  case-technical.xml  dialog-vcard-entity-search.xml  entity.xml

Ces différents fichiers sont des XForms. Les modifications que l'on va apporter correspondent à reprendre du code existant dans ces formulaires pour l'adapter à nos nouvelles balises, modifier les vocabulaires etc.

Le fichier d'entrée du formulaire est en fait*  form.xhtml*. Dans ce fichier :

  • on change le prototype utilisé (on recherche simplement lom-prototype.xml que l'on va changer par lom-rennes1-prototype.xml)
  • on ajoute un onglet rennes1 en dessous de celui de classification (en copiant collant celui de classification):

On va ensuite éditer un case-rennes1.xml en prenant exemple sur les autres case-.xml* en n'oubliant pas de déclarer l'espace de noms rennes1 et de l'utiliser !

Voici ce que peut donner ici un tel case-rennes1.xml :

Internationalisation ...

Même si on a mis des termes en dur dans le XForms ci-dessus, la facilité des widgets qu'on donne dans ori-oai-md-editor nécessite le positionnement de paramètres i18n pour ajouter/supprimer les tags que l'on à rajouter.

On ajoutera dans le fichier common/i18n/fr_FR.xml  la partie suivante (pensez à faire de même pour  common/i18n/en_EN.xml) :

Redémarrez votre serveur tomcat.

Vous devriez maintenant avoir un nouvel onglet dans votre éditeur de métadonnées !

  • No labels