Vincent Bonamy

Ajout d'une métadonnée dans un formulaire d'ORI-OAI-MD-EDITOR

Vincent Bonamy — Tue, 25 Dec 2007 08:51:00 +0100

XML permet d’étendre voir de concevoir entièrement des langages (applciations) 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.

Pour plus d’informations la dessus, vous pouvez d’ailleurs consulter ce billet précédent sur ce même blog.

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 billet tente d’expliquer comment on peut facilement é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 publique ... 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 :

<?xml version="1.0" encoding="utf-8"?>
<lom xmlns="http://ltsc.ieee.org/xsd/LOM"
     xmlns:lomur1="http://www.univ-rennes1.fr/xsd/LOMUR1">
<general>
    <identifier>
      <catalog>URI</catalog>
      <entry>http://www.univ-rennes1.fr/12345</entry>
    </identifier>
    <title>
      <string language="fr">Médecine Informatique et Écologie</string>
    </title>
    
</general>

<lomur1:lomur1>
    <lomur1:targetPublic>UMVF</lomur1:targetPublic>
    <lomur1:targetPublic>UNIT</lomur1:targetPublic>
    <lomur1:targetPublic>UVED</lomur1:targetPublic>
</lomur1:lomur1>
</lom>

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 (qui partage le projet sourcesup avec ori-oai-workflow), le répertoire spécifique à ori-oai-md-editor dans l’application Orbeon Forms est :
WEB-INF/resources/apps/ori-md-editor

On va dupliquer le formulaire lom-full, je vous liste les commandes :

[root@levain ori-md-editor]$ ls
close.xhtml config.xml i18n media page-flow.xml prototypes reload-vocab schemas welcome xforms xml-blank xpl
[root@levain ori-md-editor]$ ls xforms/
common lom-author-light lom-full oaidc-full
[root@levain ori-md-editor]$ cp -rf xforms/lom-full xforms/lom-full-extend
[root@levain ori-md-editor]$ cp xml-blank/lom-full-blank.xml xml-blank/lom-full-extend-blank.

Les formulaires en tant que tels correspondent aux sous-répertoires du répertoire xforms (excepté le répertoire common).
Les fichiers d’initialisation des formulaires en "mode standalone" (non connecté au workflow) sont les fichiers du répertoire xml-blank dont les noms doivent correspondre avec les noms des répertoires des formulaires.

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

http://ori-oai-workflow.univ-rennes1.fr/md-editor/ori-md-editor/lom-full-extend/blank

svn update !

Pour ceux qui sont connectés via subversion (et cf ce billet, on vous encourage vivement à procéder de la sorte) vous pouvez garder le répertoire .svn copié au passage dans xforms/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 :

[root@levain ori-md-editor]$ cd xforms/lom-full-extend/
[root@levain lom-full-extend]$ svn info
Path: .
URL: http://subversion.cru.fr/ori-workflow/ori-oai-md-editor/trunk/WEB-INF/resources/apps/ori-md-editor/xforms/lom-full
Repository Root: http://subversion.cru.fr/ori-workflow
Revision: 471
Node Kind: directory
Schedule: normal
Last Changed Author: vbonamy
Last Changed Rev: 471
Last Changed Date: 2007-12-16 14:05:14 +0100 (Sun, 16 Dec 2007)

[root@levain lom-full-extend]$ svn update
U case-educational.xml
U main-form.xhtml
Updated to revision 471.

prototype

Dans XForms et Orbeon Forms, l’ajout de noeud via un bouton "Ajouter un targetPublic" correspond en fait à un copier coller d’un noeud 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 pototype.

Ici, on va ajouter un prototype pour le LOM Rennes1

[root@levain ori-md-editor]$ cd prototypes/
[root@levain prototypes]$ 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. (le fichier lom-rennes1-prototype.xml est attaché à ce billet) :

....
xmlns:lomur1="http://www.univ-rennes1.fr/xsd/LOMUR1"
...
    <lomur1:lomur1>
        <lomur1:targetPublic/>
    </lomur1:lomur1>
...

Modification du formulaire

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

[root@levain ori-md-editor]$ cd xforms/lom-full-extend/ [root@levain lom-full-extend]$ ls case-annotation.xml case-educational.xml case-lifecycle.xml case-relation.xml case-technical.xml dialog-taxonomy-search.xml entity.xml case-classification.xml case-general.xml case-metametadata.xml case-rights.xml dialog-dewey-search.xml dialog-vcard-search.xml main-form.xhtml

Ces différents fichiers sont des XForms. Les modifications que l’on va apporter correspondent à reprendre du code existant dans ces formulaires pour l’adpater à nos nouvelles balises, modifier les vocabulaires etc.
Le fichier d’entrée du formulaire est en fait main-form.xhtml
Dans ce fichier main-form.xhtml

on change le prototype utilisé (on recherche simplement lom-prototype.xml que l’on va changer par lom-rennes1-prototype.xml)


<xforms:instance id="ori-prototype" src="oxf:/apps/ori-md-editor/prototypes/lom-rennes1-prototype.xml" xxforms:readonly="true" xxforms:shared="application"/>
on ajoute un onglet rennes1 en dessous de celui de classification (en copiant collant celui de classification) :
<widget:tab id="rennes1">
<widget:label>Rennes1</widget:label>
<xi:include href="http://blogperso.univ-rennes1.fr/vincent.bonamy/index.php/post/2007/12/20/case-rennes1.xml"/>
</widget:tab>

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 :

<xforms:group ref="." xmlns="http://www.w3.org/1999/xhtml"
          xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:xforms="http://www.w3.org/2002/xforms"
          xmlns:ev="http://www.w3.org/2001/xml-events"
          xmlns:xxforms="http://orbeon.org/oxf/xml/xforms"
          xmlns:xi="http://www.w3.org/2001/XInclude"
          xmlns:f="http://orbeon.org/oxf/xml/formatting"
          xmlns:lom="http://ltsc.ieee.org/xsd/LOM"
          xmlns:xhtml="http://www.w3.org/1999/xhtml"
          xmlns:widget="http://orbeon.org/oxf/xml/widget"
          xmlns:vocab="http://www.ori-oai.org/xsd/orioaivocab"
              xmlns:lomur1="http://www.univ-rennes1.fr/xsd/LOMUR1">


<fieldset>
    <legend>
          Rennes1 - Metadonnees specifiques
    </legend>

    <widget:ori-block element="lomur1:lomur1" minOccurs="0" maxOccurs="1" preceding-elements="lom:general | lom:lifeCycle | lom:metaMetadata | lom:technical | lom:educational | lom:rights | lom:relation | lom:annotation | lom:classification">

      
      <fieldset>

        <legend>
   targetPublic ...                                                                                                                                                                                         </legend>

<widget:ori-block element="lomur1:targetPublic" minOccurs="0" maxOccurs="unbounded" parent-element="lomur1:lomur1">
          <xforms:select1 ref=".">
            <xforms:item>
              <xforms:label>[Select]</xforms:label>
              <xforms:value></xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UMVF</xforms:label>
              <xforms:value>UMVF</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UNIT</xforms:label>
              <xforms:value>UNIT</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UVED</xforms:label>
              <xforms:value>UVED</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UNJF</xforms:label>
              <xforms:value>UNJF</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>AUNEGE</xforms:label>
              <xforms:value>AUNEGE</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UOH</xforms:label>
              <xforms:value>UOH</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>UNISCIEL</xforms:label>
              <xforms:value>UNISCIEL</xforms:value>
            </xforms:item>
          </xforms:select1>
        </widget:ori-block>

      </fieldset>

    </widget:ori-block>

</fieldset>

</xforms:group>

termes i18n ...

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 donc dans i18n/fr_FR.xml la partie suivante (pensez à faire de même pour i18n/en_EN.xml :

 <add-lomur1>Ajouter un bloc Lomur1</add-lomur1> <del-lomur1>Supprimer le bloc Lomur1</del-lomur1> <add-targetPublic>Ajouter un bloc TargetPublic</add-targetPublic> <del-targetPublic>Supprimer le bloc TargetPublic</del-targetPublic>

Utilisation !

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

Affichage de quelques métadonnées d'un cours choisi aléatoirement : interaction ORI-OAI et Zope

Vincent Bonamy — Sun, 23 Dec 2007 11:55:00 +0100

On met ici en place l’affichage d’un cours dans une ZPT au niveau d’un serveur d’application Zope (Zope 2).

Cette ZPT s’appuie sur une External Method qui appelle par Web Service le module ori-oai-indexing d’ORI-OAI.

On utilise ici volontairement Python/Zope pour prouver l’intégration possible d’ORI-OAI avec d’autres technologies .... il est donc tout à fait possible de faire cela bien sûr avec Ruby On Rails, Java/J2EE, php ...

External Method

Pour appleler le webservice comme décrit dans les autres billets, on passe par une External Method en Zope : un script python édité depuis la ZMI ne pourrait utiliser les librairies comme SOAPpy.

En Zope une External Method, c’est une méthode défini dans un fichier python placé dans un répertoire Extensions, l’External Method pouvant être ensuite déclaré depuis la ZMI et donc appelée depuis un script python, une zpt ...

Dans cette méthode, on veut récupérer une fiche de cours au hasard parmi les réponses à une requête lucène (qui’on paramétrera depuis la ZMI quand à elle). En fait on ne veut pas récupérer toute la fiche mais simplement quelques attributs. Pour des raisons de sécurité, on ne peut retourner simplement un objet d’un type complexe (classe que l’on aurait défini pour l’ocassion) => on se contente de renvoyer les infos sous la forme d’un dictionnaire.

On souhaite récupérér :

l’identifiant de la fiche,
le titre,
les auteurs,
les éditeurs
l’url de la notice associée dans le ori-oai-search
l’url de l’image du screenshot (construit comme indiqué dans le billet précédent).

Voici le script python oriGetRandomCourse.py :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import time
from SOAPpy import WSDL
import libxml2
import urllib
import random

def getCoursesFromOriIndexing(nbResults, luceneRequest):

    courses = []

    WSDLFILE = ’http://ori-oai-indexing.univ-rennes1.fr/indexing/xfire/IndexingService?WSDL’
    oriindexing = WSDL.Proxy(WSDLFILE)

    results = oriindexing.searchXMLDocs(luceneRequest, 1, nbResults)[’results’][’SearchResult’]
    for result in results:
        if result[’id’] != None and result[’noticeContent’]!= None:
            ide = result[’id’]
            xml_lom = result[’noticeContent’].encode(’utf-8’)
            title = getField(xml_lom, ’//lom:general/lom:title/lom:string’)
            url = getField(xml_lom, ’//lom:technical/lom:location’)
            authors_vcard = getFields(xml_lom, ’//lom:lifeCycle/lom:contribute[lom:role/lom:value="author"]/lom:entity’)
            authors_list = [[auth[3:] for auth in vcard.split(’\n’) if auth[:2] in (’FN’,’fn’)][0] for vcard in authors_vcard]
            authors = ’, ’.join(authors_list)
            editors_vcard = getFields(xml_lom, ’//lom:lifeCycle/lom:contribute[lom:role/lom:value="publisher"]/lom:entity’)
            editors_list = [[auth[3:] for auth in vcard.split(’\n’) if auth[:2] in (’FN’,’fn’)][0] for vcard in editors_vcard]
            editors = ’, ’.join(editors_list)
            url_notice = ’http://www.univ-rennes1.fr/ori-oai-search/notice.html?id=’ + ide +’&repository=’ + result[’repository’] + ’&format=’ + result[’namespace’]
            url_img_thumb = ’http://www.univ-rennes1.fr/ori-imgs/thumb-’ + ide + ’.png’
            courses.append({’ide’:ide, ’title’:title, ’authors’:authors, ’editors’:editors, ’url_notice’:url_notice, ’url_img_thumb’:url_img_thumb})
    return courses

def getField(lomXml, xpath):
    doc = libxml2.parseDoc(lomXml)
    ctxt = doc.xpathNewContext()
    ctxt.xpathRegisterNs(’lom’, ’http://ltsc.ieee.org/xsd/LOM’)
    res = ctxt.xpathEval(xpath)
    return res[0].get_content()

def getFields(lomXml, xpath):
    doc = libxml2.parseDoc(lomXml)
    ctxt = doc.xpathNewContext()
    ctxt.xpathRegisterNs(’lom’, ’http://ltsc.ieee.org/xsd/LOM’)
    results = ctxt.xpathEval(xpath)
    return [result.get_content() for result in results]

# example :
# nbResults = 1000 (results maximum)
# luceneRequest = ’md-ori-oai-namespace:("http://ltsc.ieee.org/xsd/LOM")’
def getRandomCourse(self, nbResults, luceneRequest):
    courses = getCoursesFromOriIndexing(nbResults, luceneRequest)
    nbResults = min(nbResults, len(courses))
    rand = random.randint(0,nbResults-1)
    print rand
    print courses[rand]
    return courses[rand]

La méthode qui correspond à l’External Method est getRandomCourse
On peut la tester simplement comme ceci :

Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import oriGetRandomCourse
>>> oriGetRandomCourse.getRandomCourse(None, 10, ’md-ori-oai-namespace:("http://ltsc.ieee.org/xsd/LOM")’)
9
{’url_img_thumb’: ’http://www.univ-rennes1.fr/ori-imgs/thumb-rennes1-ori-wf-1-301.png’, ’title’: "recherche d’information documentaire", ’editors’: ’UNIVERSITE RENNES 1 ’, ’url_notice’: ’http://www.univ-rennes1.fr/ori-oai-search/notice.html?id=rennes1-ori-wf-1-301&repository=ori-oai-workflow&format=http://ltsc.ieee.org/xsd/LOM’, ’authors’: ’Le Beux Pierre’, ’ide’: ’rennes1-ori-wf-1-301’}
{’url_img_thumb’: ’http://www.univ-rennes1.fr/ori-imgs/thumb-rennes1-ori-wf-1-301.png’, ’title’: "recherche d’information documentaire", ’editors’: ’UNIVERSITE RENNES 1 ’, ’url_notice’: ’http://www.univ-rennes1.fr/ori-oai-search/notice.html?id=rennes1-ori-wf-1-301&repository=ori-oai-workflow&format=http://ltsc.ieee.org/xsd/LOM’, ’authors’: ’Le Beux Pierre’, ’ide’: ’rennes1-ori-wf-1-301’}
>>> oriGetRandomCourse.getRandomCourse(None, 10, ’md-ori-oai-namespace:("http://ltsc.ieee.org/xsd/LOM")’)
5
{’url_img_thumb’: ’http://wwww.univ-rennes1.fr/ori-imgs/thumb-rennes1-ori-wf-1-291.png’, ’title’: ’tabagisme’, ’editors’: ’UNIVERSITE RENNES 1 ’, ’url_notice’: ’http://www.univ-rennes1.fr/ri-oai-search/notice.html?id=rennes1-ori-wf-1-291&repository=ori-oai-workflow&format=http://ltsc.ieee.org/xsd/LOM’, ’authors’: ’Catherine De bournonville’, ’ide’: ’rennes1-ori-wf-1-291’}
{’url_img_thumb’: ’http://www.univ-rennes1.fr/ori-imgs/thumb-rennes1-ori-wf-1-291.png’, ’title’: ’tabagisme’, ’editors’: ’UNIVERSITE RENNES 1 ’, ’url_notice’: ’http://www.univ-rennes1.fr/ori-oai-search/notice.html?id=rennes1-ori-wf-1-291&repository=ori-oai-workflow&format=http://ltsc.ieee.org/xsd/LOM’, ’authors’: ’Catherine De bournonville’, ’ide’: ’rennes1-ori-wf-1-291’}
>>>

Script Python dans Zope

Depuis la ZMI, on définit l’External Method ci avant avec pour identifiant oriGetRandomCourse
Ca nous permet depuis un objet de type "script python" avec pour identifiant oriGetRandomCourseHome créé dans la zmi de faire un :

return context.oriGetRandomCourse(1000, 'md-ori-oai-namespace:("http@//ltsc.ieee.org/xsd/LOM")')

par exemple (on ne met pas ces paramètres directement dans la zpt qui suit histoire de pouvoir tester l’appel de l’external method, depuis le script, de pouvoir modifier simplement les paramètres dans le script et non en retouchant la zpt etc).

ZPT

La zpt n’a plus qu’à appeler le script ci-avant, et afficher les éléments du cours, par exemple :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">

<head>
    <title>test random course ...</title>
</head>

<body>
    <div tal:define="course here/oriGetRandomCourseHome">

      <h2 tal:content="python: course[’title’]"/>
      <div>
    <span class="style_4">Auteur : 
    <span
        tal:replace="python: course[’authors’]">Le nom de l’auteur</span></span>
    <br/>
    <span tal:content="python: course[’editors’]"/>

    <br/>

    <a href="http://blogperso.univ-rennes1.fr/vincent.bonamy/index.php/post/2007/12/20/#" tal:attributes="href python:course[’url_notice’]">
    <img src="http://blogperso.univ-rennes1.fr/vincent.bonamy/index.php/post/2007/12/20/#"
           alt="" border="1"
           style="border: medium double grey; height: 75px; width:100px;"
           tal:attributes="src course/url_img_thumb"/>
    </a>
      </div>
    </div>

</body>

Voici ce que ca donne alors :

Screenshots de ressources numériques

Vincent Bonamy — Sat, 22 Dec 2007 10:57:00 +0100

Ce billet présente une solution légère de captures d’écran de ressources numériques.

Dans cette solution, on interroge par python le module ori-oai-indexing pour extraire les urls et identifiants des ressources indexées.

Par le biais d’un serveur X virtuel (Xvfb) on utilise ensuite sur un serveur (sans interface graphique) un certain nombre d’outils permettant de réaliser des "captures d’écran" des ressources identifiées par les urls.

Ce billet aborde en fait plusieurs points qui peuvent être repris de manière indépendante : dans un contexte hors ORI-OAI notamment.

Face à des solutions comme browsershots la solution est ici légère et simple mais elle reste dans le domaine du "bricolage" (qui marche cependant ! :-) ).

Récupération des ids et urls des ressources

On utilise comme dans un billet précédent la méthode searchXMLDocs du module ori-oai-indexing.
On récupère l’identifiant directement depuis un dictionnaire.
Pour l’url on s’impose le fait de résoudre un XPath en Python -> on aurait aussi pu plus simplement utiliser la méthode searchFromAttributes qui à priori peut nous renvoyer directement l’id et l’url par exemple (cf IndexingServiceInterface.java).

Pour l’appel du Web Service SOAP, on continue bien évidemment avec SOAPpy.
Pour la résolution du Xpath, on choisit libxml2, le binding python de la librairie C.
=> sous debian :
apt-get install python-libxml2

Voici les 2 méthodes qui implémentent ces 2 aspects (l’une appelant l’autre) :

def getUrlsIdsFromOriIndexing():

    urls_ids = []

    WSDLFILE = ’http://ori-oai-indexing.univ-rennes1.fr/indexing/xfire/IndexingService?WSDL’
    oriindexing = WSDL.Proxy(WSDLFILE)
    request = ’md-ori-oai-namespace:("http://ltsc.ieee.org/xsd/LOM")’

    results = oriindexing.searchXMLDocs(request, 1, 5)[’results’][’SearchResult’]
    for result in results:
        if result[’id’] != None and result[’noticeContent’]!= None:
            ide = result[’id’]
            url = getUrl(result[’noticeContent’].encode(’utf-8’))
            urls_ids.append((ide, url))
    return urls_ids



def getUrl(lomXml):
    doc = libxml2.parseDoc(lomXml)
    ctxt = doc.xpathNewContext()
    ctxt.xpathRegisterNs(’lom’, ’http://ltsc.ieee.org/xsd/LOM’)
    res = ctxt.xpathEval("//lom:technical/lom:location")
    return res[0].get_content()

Notez que l’on a ici volontairement positionné le lastNotice de la méthode searchXMLDocs à 5 pour tester plus facilement.
Notez également l’utilisation des espaces de noms (namespaces) au travers de libxml2 :

on définit un binding préfixe / espace de noms : ctxt.xpathRegisterNs('lom', 'http://ltsc.ieee.org/xsd/LOM')
on utilise ce binding dans la résolution d’un XPath : ctxt.xpathEval("//lom:technical/lom:location")

Voici ce que donne l’appel de la méthode getUrlsIdsFromOriIndexing() dans une console python (le fichier python étant shot.py):

>>> import shot
>>> shot.getUrlsIdsFromOriIndexing()
[(’rennes1-ori-wf-1-295’, ’http://www.med.univ-rennes1.fr/wkf/stock/RENNES20071019121406burgunsondages08.pdf’), (’rennes1-ori-wf-1-289’, ’http://www.med.univ-rennes1.fr/wkf/stock/RENNES20061221025012lepogampLA_FONCTION_RENALE.doc’), (’rennes1-ori-wf-1-285’, ’http://www.med.univ-rennes1.fr/wkf/stock/RENNES20060915113249tbuiPoly_SEmio_2006.pdf’), (’rennes1-ori-wf-1-283’, ’http://www.med.univ-rennes1.fr/wkf/stock/RENNES20060613052202duvauferBases_en_radioanatomie_1.ppt’), (’rennes1-ori-wf-1-287’, ’http://www.med.univ-rennes1.fr/wkf/stock/RENNES20061213113922deugnierAnatomoPhysioFoie.doc’)]
>>>

Stratégie de Captures ...

On l’a évoqué en introduction, browsershots est une solution relativement complète pour faire des captures d’écran des ressources webs : il permet d’utiliser des postes clients distants pour réaliser les captures : les postes clients étant +/- "pilotés" par le serveur.
Pratique, mais un serveur ne suffit pas, il faut des postes clients, cela peut être lourd à mettre en place surtout dans une première phase de mise en place de captures sur un nombre de ressources relativement limités ...

Aussi l’idée ici est de n’utiliser que le serveur lui-même, qui plus est, n’a pas de serveur X. On ne souhaite pas installer sur le serveur une interface graphique Gnome ou autre.

Une "capture d’écran" étant une image, on a théroiquement 2 "possibilités" :
* faire vraiment une capture d’écran d’un client X interprétant la ressource numérique (html, pdf, flash, ppt ...)
* transformer/convertir la ressource en une image.

En fait suivant les cas, on choisira la méthode la plus simple selon le format donné.
=>

pour html/flash, il parait plus simple d’utiliser un navigateur comme firefox et de faire une copie d’écran.
pour le pdf, on pourrait utiliser un plugin dans le navigateur, mais on n’a pas forcément envie d’installer ce genre de chose ... d’autant que ghostscript, outil libre, peut par exemple nous convertir une page pdf complète en une image via une ligne de commande.
pour les autres formats, je vous laisse y réfléchir et donner des idées en commentaires si vous le souhaitez ;-) [openoffice.org ? pptview ? etc.]

Mise en place des Captures ...

Firefox

Il faut installer Firefox sur le serveur, mais pour qu’il puisse tourner, il faut aussi installer un serveur X virtuel que l’on démarrera lorsqu’on aura besoin de Firefox simplement : Xvfb par exemple.

On démarrera Firefox comme cela :

Xvfb :1 -screen 0 1280x960x24&
firefox --display=:1 http://www.univ-rennes1.fr

Pour la capture on peut utiliser import par exemple fourni avec imagemagick, d’autant qu’une fois la capture faite, imagemagick pourra nous servir également pour retravailler nos images à souhait : en faire des vignettes (thumbnail), y mettre un effet shadow (ombre), etc.

Un des soucis que l’on peut rencontrer avec Firefox cependant est que la taille de la fenêtre de firefox ne s’ouvrira pas forcément en grand ... dans certaines versions on a l’option -fullscreen de disponible mais pas dans toutes.

Un certain nombre d’extensions firefox peuvent résoudre habilement ce problème, on peut utiliser :

rkiosk
ET fullerscreen

conjointement.
Le problème est : comment installer une extension Firefox sur un serveur qui ne contient pas d’X ? -> pas de possibilité de cliquer dans une boîte de dialogue ou autre ....

Une solution simple : installer les extensions sur un firefox sur un poste en local sous un profil donné (bénéficant d’une interface graphique), en profiter pour configurer le firefox comme on le souhaite (on peut ajouter des extensions aussi pour supporter d’autres formats par exemple ... d’ailleurs si vous avez des idées, n’hésitez pas à nous les donner dans les commentaires ;-) ), puis copier coller le profil ainsi créé (voir le répertoire .mozilla/firefox) sur le serveur (on spécifie l’utilisation de ce profil par défaut dans .mozilla/firefox/profiles.ini) ... le tour est joué !

Ghostscript

Il faut l’installer (apt-get) et voir ses nombreuses possibilités, par exemple :

gs -dNOPAUSE -sDEVICE=png256 -q -dBATCH -sOutputFile=test.png test.pdf

Imagemagick

De même, installez le (apt-get toujours si vous êtes sur debian :-) ) et voyez toutes ses possibilités !

Le script ... !

Ici pour tout ce "bricolage" on va faire un petit script python, qui

va récupérer les urls et ids depuis l’indexing
=> cf plus haut : SOAPpy + libxml2
va regarder si le format du fichier derrière l’url correspond à html ou un pdf
=> librairie urllib2
va appeler les programmes xvfb, firefox, ghostscript, imagemagick qui vont bien.
=> librairie os

=> Le script complet est affiché ici et est également en fichier attaché à ce billet.

#!/usr/bin/env python # -*- coding: utf-8 -*- import os import time from SOAPpy import WSDL import libxml2 import urllib def closeFirefox(): os.system('killall -3 firefox') os.system('killall -9 firefox-bin') def closeXvfb(): os.system('killall -9 Xvfb') def initXvfb(): psXvfb = os.popen('ps -edf | grep Xvfb').readlines() if len(psXvfb) < 3: os.system('Xvfb :1 -screen 0 1280x960x24&') #os.system('Xvfb :1 -screen 0 1024x768x24&') time.sleep(3) def launchFirefox(url): psFirefox = os.popen('ps -edf | grep firefox').readlines() if len(psFirefox) < 3: print '##### open url ... :' + url os.system('firefox --display=:1 ' + url + ' &') #wid = os.popen('DISPLAY=:1 wmctrl -lp | grep firefox | cut -f1 -d\ ').readlines[0] #print wid #os.popen('DISPLAY=:1 wmctrl -i -r ' + wid + ' -b toggle,fullscreen,above') time.sleep(3) def shot(name, url): try: url_open = urllib.urlopen(url) infos = url_open.info() typ = infos.gettype() if url_open.geturl()[:5] != 'https': typ = typ if typ == 'text/html': # os.system('DISPLAY=:1 firefox -remote "openurl(' + url + ')"') launchFirefox(url) time.sleep(10) os.system('DISPLAY=:1 import -window root ' + name + '.png') closeFirefox() if typ == 'application/pdf': urllib.urlretrieve(url,name) os.system('gs -dNOPAUSE -sDEVICE=png256 -q -dBATCH -sOutputFile=' + name +'.png ' + name) time.sleep(1) except: print 'error ...' def thumb(img): os.system('cp ' + img +'.png ' + 'thumb-' + img +'.png ') os.system('mogrify -thumbnail 100 thumb-' + img +'.png') def thumb300(img): os.system('cp ' + img +'.png ' + 'thumb300-' + img +'.png ') os.system('mogrify -thumbnail 300 thumb300-' + img +'.png') def vignette(img): os.system('convert ' + 'thumb-' + img + '.png -bordercolor grey60 -border 1 -background black $ +clone -shadow 60x4+4+4 $ +swap -background none -flatten -depth 8 ' + 'vign-thumb-' + img + '.png') def getUrlsIdsFromOriIndexing(): urls_ids = [] WSDLFILE = 'http://localhost:6380/ori-oai-indexing/xfire/IndexingService?wsdl' oriindexing = WSDL.Proxy(WSDLFILE) request = 'md-ori-oai-namespace:("http://ltsc.ieee.org/xsd/LOM")' results = oriindexing.searchXMLDocs(request, 1, 5)['results']['SearchResult'] for result in results: if result['id'] != None and result['noticeContent']!= None: ide = result['id'] url = getUrl(result['noticeContent'].encode('utf-8')) urls_ids.append((ide, url)) return urls_ids def getUrl(lomXml): doc = libxml2.parseDoc(lomXml) ctxt = doc.xpathNewContext() ctxt.xpathRegisterNs('lom', 'http://ltsc.ieee.org/xsd/LOM') res = ctxt.xpathEval("//lom:technical/lom:location") return res[0].get_content() closeXvfb() closeFirefox() initXvfb() print 'init Xvfb ok ...' for (id, url) in getUrlsIdsFromOriIndexing(): url = url.replace('https','http') print url + " ... : " + id shot(id, url) thumb300(id) thumb(id) vignette(id) closeXvfb() print 'close Xvfb ok ...'

On notera cependant que

on relance firefox pour chaque capture plutôt que de rouvrir une page dans le même onglet principal (cela afin d’éviter de rester sur une boîte de dialogue quelconque; javascript [qu’on désactivera cependant peut-être], certificat ssl non valide, etc.
on tente pour les accès https, de voir si vraiment on ne peut pas atteindre l’url en http
on choisit de ne pas faire de captures des pages en https
etc.

Utilisation dans ori-oai-search ...

Ensuite, dans le cadre d’ori-oai, et parcequ’on a soigneusement nommé nos images via l’identifiant de chaque notice, on peut facilement modifier directement la page jsp des résultats d’ori-oai-search pour intégrer ces captures.
voici alors ce que vous poiuvez obtenir :

Appel de Web Services avec Python

Vincent Bonamy — Fri, 21 Dec 2007 10:22:00 +0100

Les modules ORI-OAI (tous écrits en Java) s’interconnectent uniquement par Web Service (SOAP).

Un intérêt fondamental des Web Services est leur indépendance vis à vis des technologies utilisées, cet aspect étant garanti par le respect de WS-I Basic Profile.

Aussi, on montre ici comment on peut appeler facilement une méthode du Web Service du module ori-oai-indexing par exemple via python !

La signature du WS ... ?

Usuellement on peut retrouver les signatures des méthodes exposées par Web Service via le WSDL qui décrit les Web Service.
Depuis le ori-oai-indexing de Rennes1, on pourra le retrouver ici par exemple :
http://ori-oai-indexing.univ-rennes1.fr/indexing/xfire/IndexingService?WSDL
(fichier correspondant joint au billet).

Certaines technologies peuvent à partir de ce WSDL générer des classes, des fichiers qui permettent ensuite d’appeler les méthodes du Web Service.
Dans d’autres cas, le but est juste de permettre au programmeur de connaitre la façon dont il doit coder sa requête : nbre de paramètres et types de ceux-ci, etc.

Si on avait à coder un client au Web Service du module ori-oai-indexing en Java, on utiliserait directement, en plus de l’url du Web Service (donné ci dessus), l’interface Java utilisé dans le module de ori-oai-indexing : IndexingServiceInterface.java. Avec des outils adaptés (XFire/CXF ou autre ...), c’est la solution la plus confortable et efficace pour le dévelopeur.

=> en fait finalement, un dévelopeur qui souhaite connaîtré la signature d’un web service comme celui d’ori-oai-indexing a finalement 2 options :

le Wsdl
l’interface en Java

Personnellement, les 2 sont compréhensibles, mais l’interface Java est plus simple et concise et surtout ... elle est commentée :-)

Appel du Web Service en Python

L’appel d’un Web Service du type SOAP comme l’est le WS de ori-oai-indexing se fait simplement en python, du moment que l’on ait le package SOAPpy

Sous debian par exmple un simple
apt-get install python-soappy
fait l’affaire :-)

On va choisir d’appeler la méthode
public SearchResults searchXMLDocs(String request, int firstNotice, int lastNotice)du ori-oai-indexing de Rennes1.

Le request est un String, en fait c’est une requête lucene. Ici on peut requêter par exemple les éléments dont l’index md-ori-oai-namespace est à http://ltsc.ieee.org/xsd/LOM
[notez que dans le cadre de ori-oai-indexing, on peut retrouver ce genre d’informations en regardant les fichiers de configs par exemple].
Notre requête sera (cf documentation de lucène directement) :

md-ori-oai-namespace:("http@//ltsc.ieee.org/xsd/LOM")

Le firstNotice et le lastNotice peuvent être placés pour l’exemple à 1 et 4 par exemple ....

Et pour le type de résultat obtenu : SearchResults - 3 solutions :

on regarde dans le wsdl à quoi cela correspond
on regarde dans l’API Java de ori-oai-indexing à quoi cela correspond
on fait confiance à python pour nous aider une fois qu’on aura récupéré un exemple de résultats

On prendra ici la 3ème solution d’autant que l’on va manipuler tout cela via la console python.

Du code python vaut maintenant mieux qu’un long discours :

vincent@debian:~$ python Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from SOAPpy import WSDL >>> WSDLFILE = 'http://ori-oai-indexing.univ-rennes1.fr/indexing/xfire/IndexingService?WSDL' >>> oriindexing = WSDL.Proxy(WSDLFILE) >>> request = 'md-ori-oai-namespace:("http@//ltsc.ieee.org/xsd/LOM")' >>> results = oriindexing.searchXMLDocs(request, 1, 4)

Arrivé ici, on a appelé le Web Service de l’indexing et on a mis le résultat dans la variable results.
Tout s’est bien passé (sinon pas d’inquiétude, python nous aurait prévenu via un Traceback !).

Reste à savoir ce qu’il y a dans results ... => il suffit de l’afficher :

>>> results
<SOAPpy.Types.structType out at -1217116660>: {’numberOfResults’: ’577’, ’results’: <SOAPpy.Types.structType results at -1217115252>: {’SearchResult’: [<SOAPpy.Types.structType SearchResult at -1217115412>: {’attributesValues’: None, ’repository’: ’ori-oai-workflow’, ’namespace’: ’http://ltsc.ieee.org/xsd/LOM’, ’datestamp’: ’20071219’, ’id’: ’rennes1-ori-wf-1-295’, ’noticeContent’: u’<lom:lom xmlns:lom="http://ltsc.ieee.org/xsd/LOM" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">\n <lom:general>\n <lom:title>\n <lom:string language="fr">sondages-estimation</lom:string>\n

...... etc.

On voit que le résultat est donné sous forme d’un dictionnaire qui a pour valeur un dictionnaire qui a pour valeur une liste qui a pour valeur .... etc.
Bref, une forme bien pratique en python, car composé de types simple :-)

Aussi pour avoir par exemple le ’id’ de la première fiche on demandera :

>>> results['results']['SearchResult'][0]['id']
'rennes1-ori-wf-1-295'

On trouvera la notice complète de la fiche via :

>>> results['results']['SearchResult'][0]['noticeContent'] u'<lom:lom xmlns:lom="http://ltsc.ieee.org/xsd/LOM" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd">\n <lom:general>\n <lom:title>\n <lom:string language="fr">sondages-estimation</lom:string>\n </lom:title>\n <lom:identifier>\n <lom:catalog>URI</lom:catalog>\n <lom:entry>http://ori-oai-search.univ-rennes1.fr/uid/rennes1-ori-wf-1-295</lom:entry>\n </lom:identifier>\n <lom:language>fr</lom:language>\n <lom:description>\n <lom:string language

etc. ....

Conclusion

En conclusion, ce billet va en ammener d’autres sur l’utilisation de cet appel Web Services sur :

la mise en place d’un script pour réaliser des screenshots automatiques des ressources numériques récupérés depuis le module ori-oai-indexing
l’affichage de quelques métadonnées d’un cours choisi aléatoirement dans ori-oai depuis Zope

A suivre donc ... !

XML et les espaces de noms ...

Vincent Bonamy — Fri, 21 Dec 2007 09:19:00 +0100

Dans le cadre de plusieurs projets (LOMFR et ORI-OAI), j’ai tenté d’expliquer par écrit le concept des espaces de noms en XML qui, bien que fondamental en XML, n’est pas toujours bien compris et donc pas toujours bien respecté.

Espaces de Noms - rappel

Les espaces de noms en XML sont une recommandation du W3C. Ils permettent d’identifier de manière unique les éléments et attributs des fiches XML. De fait, ils permettent de mettre en oeuvre le côté eXtensible de XML.

Aussi lorsque l’on définit un "langage XML" (on devrait d’ailleurs plutôt parler d’ "application XML") dont les instances/fiches sont destinées à être des formats/vecteurs d’échange d’information entre plusieurs entités (logicielles ou non), il est important voir même impératif d’associer à ce nouveau langage un voir plusieurs espaces de noms XML (pré-existants et/ou nouvellement créés).
Un espace de noms s’applique aux éléments et attributs des fichiers XML. De manière pragmatique, chacun des éléments et attributs utilisés dans des fichiers XML d’échange devrait être déclaré dans un espace de noms (cela excepté les potentiels éléments/attributs réservés en XML).
Spécifier que des éléments et attributs sont dans un espace de noms donné, c’est garantir que ces éléments et attributs répondent au langage (implémentant un standard, une norme ...) identifié par l’espace de noms.

Un espace de noms est donné/représenté par un identifiant : une URI (Uniform Resource Identifier) qui est généralement une URL (il faut noter que cette URL ne pointe pas forcément sur un document existant : c’est bien un identifiant). Cet identifiant est utilisé via l’attribut réservé en XML xmlns qui permet dans une fiche XML de spécifier (via un préfixe ou non dans le cas de l’espace de noms par défaut) ensuite que l’on utilise tel élément ou tel attribut de tel espace de noms. Finalement, cela permet d’identifier de manière unique les éléments et attributs d’un "langage XML" : c’est le couple espace de noms et nom de l’élément/attribut qui permet cette identification.

L’exemple suivant
<title xmlns="http://dummy.univ-rennes1.fr/xsd/dummy" />
est par exemple équivalent à :
<toto:title xmlns:toto="http://dummy.univ-rennes1.fr/xsd/dummy" />
mais non équivalent à
<title xmlns="http://dummy.cndp.fr/xsd/dummy" />
L’élément title issu de http://dummy.univ-rennes1.fr/xsd/dummy et l’élément title issu de http://dummy.cndp.fr/xsd/dummy ne sont pas similaires, ils représentent 2 balises différentes qui répondent à 2 langages différents dans 2 espaces de noms différents.

Les différents logiciels qui manipulent des fichiers XML d’un langage XML donné doivent utiliser les espaces de noms au travers de parsers XML et autres outils pour assurer un réel support du langage concerné.
En XML, il est possible de vérifier que les éléments et attributs d’un fichier XML sont techniquement bien formés par rapport aux espaces de noms auxquels ces éléments et attributs font référence.
Pour ce faire, les technologies XML disposent de plusieurs outils : DTD, XML Schema, RELAX NG, Schematron ...
Cette phase de validation est nécessaire dans le cadre de la validation d’une fiche XML par rapport à un langage donné.

Espaces de Noms – LOM

Le standard LOM utilise naturellement un espace de noms spécifique LOM http://ltsc.ieee.org/xsd/LOM qui permet donc d’identifier les ressources LOM. Lorsqu’on utilise cet espace de noms LOM dans des fiches XML, on s’engage donc en quelque sorte à respecter le standard qu’est le LOM.

Pour pouvoir valider le format des fiches XML LOM, le LOM propose des schémas XML LOM disponibles en ligne.

Le schéma http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd (qui correspond en fait à lomStrict.xsd) est la déclinaison ? stricte ? de LOM : ce schéma ne permet pas l’utilisation conjointe d’un autre espace de noms que l’espace de noms LOM dans une fiche dite LOM.
Le schéma lomLoose http://ltsc.ieee.org/xsd/lomv1.0/lomLoose.xsd autorise quand à lui une utilisation conjointe de l’espace de noms LOM et d’autres espaces de noms. Lorsque l’on décide de produire et manipuler du LOM ou une extension de celui-ci, la validation technique des fiches en lomLoose est nécessaire, elle n’est cependant pas suffisante.
Aussi dans le cadre d’un projet comme LOMFR qui vise à étendre le LOM, il est nécessaire de proposer des outils permettant de valider au mieux les fiches LOMFR .

Espaces de Noms – LOMFR

Au niveau du LOMFR, l’espace de noms officiel associé à la norme est http://www.lom-fr.fr/xsd/LOMFR.

Le LOMFR étend le LOM en

proposant de nouveaux éléments/attributs,
proposant de nouveaux vocabulaires,r
endant obligatoire/unique certains éléments/attributs,
supprimant certains éléments/attributs,
supprimant certains vocabulaires.

Dans une fiche LOMFR, l’espace de noms LOMFR est à utiliser conjointement à l’espace de noms LOM. Les éléments et attributs issus de LOM doivent naturellement être déclarés dans l’espace de noms LOM http://ltsc.ieee.org/xsd/LOM, les éléments et attributs issus du LOMFR doivent être donnés dans l’espace de noms LOMFR http://www.lom-fr.fr/xsd/LOMFR.

Espaces de Noms – LOMFR - Outils

Afin d’aider au mieux les développements d’outils, la mise en place d’échange entre plusieurs entités etc. autour du LOMFR, le LOMFR proposera un certain nombre d’outils, de recommandations, de bonnes pratiques autour de la norme LOMFR.
Parmi eux, on trouvera des schémas et schématrons XML qui permettent de valider une fiche LOMFR : ils valident à la fois les éléments LOM (en prenant en compte les spécificités apportés par LOMFR : suppression/cardinalité de certains éléments/vocabulaires) ainsi que les éléments LOMFR.

Espaces de Noms – Conclusion

Déclarer dans un XML que les éléments et attributs utilisés proviennent des espaces de noms LOM et LOMFR, c’est identifier le XML comme répondant à la norme LOMFR. La validation des fichiers XML est une condition nécessaire pour s’assurer que ces fichiers respectent bien ce contrat ainsi passé. La possible interopérabilité des fichiers XML LOMFR entre les plateformes d’échange (de type OAI-PMH par exemple), la compatibilité des outils d’éditions, etc. ne peuvent être réalités que si ces règles (et donc la prise en compte des espaces de noms) sont scrupuleusement respectées.

C’est également le respect de ces règles qui permet une interopérabilité des fiches LOM (dont les fiches LOMFR, et toutes autres fiches dont le langage étend LOM) au niveau des différents outils LOM.

Exploitation d'applications avec subversion - installation et mises à jour.

Vincent Bonamy — Thu, 20 Dec 2007 09:48:00 +0100

Subversion est un outil de versioning puissant. Basé sur un modèle centralisé, il a l’avantage de rester relativement simple.

L’utilisation d’ouil de versioning chez les dévelopeurs s’est aujourd’hui réellement généralisé, au point que faire sans n’est maintenant plus envisageable.

Pour le métier de l’exploitant pourtant, l’utilisation de tels outils libres et open sources semble tarder à venir. Pourtant c’est une pratique qui peut faciliter grandement la vie de l’exploitant ... à l’utilisation l’exploitant devrait même être logiquement encore plus gourmand et exigeant quant aux possibilités de tels outils ...

Cet article décrit l’installation d’un logiciel/application (ici ori-oai-workflow-spring) en utilisant subversion (de sourcesup). Puis il montre comment subversion peut aider l’exploitant à mettre à jour son application tout en conservant les modifications qu’il aura apportées dans les configurations, voir dans le code de l’application !

Nous proposons ici d’installer ori-oai-workflow-spring, de le configurer puis de le mettre à jour avec l’outil subversion.

Ce principe peut être bien sûr adapté à l’installation d’autres applications disponibles via subversion (comme les différents modules ORI-OAI, mais pas seulement) et aussi à d’autres outils que subversion comme CVS, mais aussi des outils plus puissants comme Mercurial, qui bien utilisé, ammènerait d’ailleurs encore bien plus de possibilités que subversion pour l’exploitant ...

Checkout d’ori-oai-workflow-spring 0.8.3

Plutôt que de télécharger une version d’ori-oai-workflow-spring sous forme d’archive, on télécharge ici la version taguée dans le subversion de sourcesup.

Comprenez bien qu’ici on se place en tant qu’exploitant, on utilise donc le subversion en mode anonyme, donc sans avoir les droits d’écriture sur le repository.
De plus, on préfère l’utilisation de subversion en ligne de commande via la commande svn sur un serveur linux (a priori pour ce genre d’opération, vous serez connecté sur un serveur distant sans Interface Graphique, en SSH).

sourcesup propose 2 modes de navigation dans un repository subversion :

via viewvc : propose une navigation agréable dans le repository svn : coloration syntaxique du code, logs, etc
directement via l’interface dav-svn (apache) de subversion avec l’url suivant http://subversion.cru.fr/ori-workflow/ : c’est cette dernière url qui permet à l’outil client svn de venir synchroniser votre répertoire d’installation avec le repository svn distant.

=> Pour l’exemple on récupère via svn ("checkout") la distribution ori-oai-workflow-spring-0.8.3 grâce à cette url : http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3/

L’idée étant de mettre à jour ori-oai-workflow-spring au fur et à mesure des nouvelles versions, on crée un répertoire source avec pour nom ori-oai-workflow-spring-svn (en omettant donc le numéro de version.
mkdir ori-oai-workflow-spring-svn

Ensuite voici la commande checkout à faire depuis ce répertoire ori-oai-workflow-svn :
svn checkout http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3 .

Copie d’écran :

L’ensemble des fichiers est ainsi récupéré un à un et ajouté (le A signifiant Add) pour la première fois à votre répertoire d’installation.

Configurations d’ori-oai-workflow-spring 0.8.3

Les documentations d’installation aidant, on modifie les fichiers build.properties et conf/properties/main-config.properties pour que cela corresponde à nos besoins propres.
Rapidement, une nouvelle capture d’écran montrant l"’édition de ces fichiers :

Une fois fait, svn est capable de nous résumer les modifications via la commande
svn status

Les fichiers listés avec M indique que ces fichiers ont été modifiés (M pour Modify).

Une commande svn diff permet de visualiser les différences apportées par rapport à la distribution originale.
Exemple d’un diff sur build.properties :

Ce sont des fichiers de diff classiques qui en ressortent : les + et - indiquent si la ligne est ajoutée/modifiée par rapport à la distribution originale.

Bien sûr ici, et notamment pour le module ori-oai-workflow-spring, l’exploitant va configurer un bon nombre de fichiers, modifier les css, les logos etc.
Ensuite il déploiera l’application dans un Tomcat (cf le build.properties) ... et viendra le temps de la mise à jour ... !!

Mise à jour d’ori-oai-workflow : 0.8.3 -> 1.0.0

Un svn info nous permet de constater que nous sommes bien sur le tag 0.8.3, c’est à dire sur l’url :
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3

Mettre à jour ori-oai-workflow, c’est ici le passer (on dit qu’on le switch) de 0.8.3 à 1.0.0.
Cette manipulation subversion peut avoir des effets non contrôlés, c’est une manipulation qui suivant les cas peut être délicat.
Pour plus de sûreté, on propose avant de faire un switch de sauvegarder l’ensemble du répertoire ori-oai-woirkflow-svn, on peut faire un tar-gz par exemple simplement :
tar czf ori-oai-workflow-svn-backup.tgz ori-oai-workflow-svn

On récupèrera la nouvelle url correspondant à la version 1.0.0 via un navigateur : ici, c’est
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-1.0.0

Donc depuis le répertoire ori-oai-workflow-spring-svn on peut procéder au switch :

Le U nous indique ici les fichiers directement mis à jour,
Le A les fichiers ajoutés,
Le G les fichiers mis à jour qui ont nécessité une résolution de conflits car modifiés à la fois par l’exploitant et le développeur.
Les fichiers marqués en G sont donc usuellement à vérifier rapidement : on vérifie leur intégrité, on peut pour cela utiliser la commande svn diff pour voir les différences entre le fichier de l’exploitant et le fichier original de la version 1.0.0 d’ori-oai-workflow (la plupart du temps, on peut faire confiance à subversion et au dévelopeur qui a conscience du procédé mis en oeuvre et qui agit au niveau du développement en conséquence ....).
Ici il n’y a pas de conflit (marqué C) et donc tout s’est extrêmement bien passé. A priori il n’y a pas grand chose à faire de plus pour cette mise à jour (mis à part bien sûr suivre les indications de la documentation : faire pour le workflow un ant upgrade par exemple ici puis redéployer l’application).

L’avantage ici est que l’on n’a pas eu à recopier et répercuter soit même les modifications de configuration entre une ancienne et une nouvelle.
Cependant, et même si le dévelopeur, en connaissance de cause, prend garde à faire en sorte que ces switchs se passent au mieux, il se peut que l’on rencontre parfois des "conflits".

Mise à jour d’ori-oai-workflow : conflits !

Comme dit ci-avant, usuellement lorsque le dévelopeur y prend garde, il est normalement rare d’aboutir à un conflit. Mais cela arrive tout de même, notamment lorsque (contrairement au paragraphe ci-avant) à la fois

un certain nombre de modifications entre 2 versions ont été faites côté développement.
un certain nombre de configurations/personnalisations ont été faites côté exploitation.

Ici on se met dans une situation où on aura lors du switch un conflit.
Pour cela on se place comme un exploitant qui a chargé via svn le tag 0.6.4 de ori-oai-workflow et qui a modifié quelques fichiers de configurations et autre, notamment le fichier CSS WebContent/media/ori-addon.css :

On procède au switch vers le tag 1.0.0 directement :

Dans la copie d’écran, on ne donne pas le listing complet, mais la plupart des fichiers sont notés U, d’autres A, quelques uns G et surtout le fichier WebContent/media/ori-addon.css est noté C.

On peut d’ailleurs retrouver les fichiers notés C via un svn status :

L’édition de ori-addon.css pour une résolution manuelle du conflit est impératif.
Ici une modification a été faite en parallèle par le développeur et par l’exploitant. On peut retrouver les différentes versions de ce fichier dans les fichiers nommés ori-addon.css.*
Dans le fichier ori-addon.css on retrouvera les caractères <<<<<<< , ======= et >>>>>>> nous permettant d’identifier les régions du ou des conflits.

=> finalement on modifiera simplement ici

<<<<<<< .mine
    background: red url( ../media/icons/door_out.png ) no-repeat left center;
    border: solid 1px #999999;
=======
    background: transparent url( ../media/icons/door_out.png ) no-repeat left center;
    border: none;
>>>>>>> .r471

par


    background: red url( ../media/icons/door_out.png ) no-repeat left center;

    border: none;

par exemple.

Les conflits résolus, on supprimera alors les fichiers ori-addon.css.*.

Conclusion

Bien utilisé à la fois au niveau du dévelopeur que de l’exploitant, subversion peut devenir une arme redoutable pour l’exploitant également (et non plus pour le dévelopeur uniquement).
Pour certaines applications comme ori-oai-workflow qui permet une configuration fine et poussée via la modification de fichiers de configuration, l’exploitant a tout intérêt à utiliser et exploiter au maximum subversion ... côté exploitation !

Éditeur de métadonnées : DC OAI_DC LOM LOMFR etc.

Vincent Bonamy — Wed, 19 Dec 2007 22:03:00 +0100

ORI-OAI ... rappel !

ORI-OAI ( http://www.ori-oai.org ) est un logiciel Libre et OpenSource. Il vise à la création d’un réseau de portails OAI (OAI-PMH) en proposant des outils pour référencer et indexer les ressources notamment numériques.

Les différents modules qui constituent ORI-OAI ont été conçus de manière indépendante pour permettre une adaptation des solutions ORI-OAI à des contextes applicatifs pré-existant.

Ainsi ils communiquent entre eux via des Web Services relativement légers et facilement réutilisables par d’autres applications. Même si ces modules sont développés en Java/J2EE, ils peuvent tout à fait être utilisés via des applications de technologie différente comme python, ruby, ... cela notamment parceque ces Web Services respectent WS-I Basic Profile.

ORI-OAI-MD-EDITOR: l’Éditeur de métadonnées !

Un des modules de ORI-OAI est l’éditeur de métadonnées (basé sur Orbeon Forms) que l’on a nommé ORI-OAI-MD-EDITOR. Il peut, comme chacun des autres modules, être utilisé/repris dans un certain nombre d’applicatifs.

ORI-OAI est open source (GPL), l’éditeur également (Orbeon Forms que l’on livre avec l’éditeur est sous licence LGPL).

Comme chacun des modules de ORI-OAI, Les documentations techniques, les sources, distributions etc se trouvent sur la plateforme de développement SourceSup,
http://sourcesup.cru.fr/softwaremap/trove_list.php?form_cat=318

Concernant ORI-OAI-MD-EDITOR, celui-ci partage actuellement un projet avec le module ori-oai-workflow :
http://sourcesup.cru.fr/projects/ori-workflow/

ORI-OAI-MD-EDITOR: une application Orbeon Forms

Orbeon Forms est une application J2EE qui utilise XForms côté serveur pour proposer dans un navigateur des interfaces Web Ajax. XForms, recommandation W3C, est une technologie qui permet de décrire en XML des formulaires manipulant des fichiers XML. XForms a vocation a tourné côté client, c’est à dire à être directement interprété par un navigateur web, mais aussi un téléphone portable, etc.
Les navigateurs usuels ne supportent actuellement pas XForms en natif. Des plugins sont cependant disponibles pour Firefox et IE par exemple, mais ceux-ci ont du mal à convaincre face à l’engouement qu’il y a autour d’Ajax.
Pourtant XForms est une réponse du W3C très élégante à ce besoin d’interactivité exprimé au travers du succès d’Ajax ... bref, en attendant que XForms (ou une technlogie similaire) perce côté client, Orbeon Forms propose l’interprétation de XForms côté serveur pour générer une interface Ajax aux navigateurs. Il permet donc de coder une application Ajax en utilisant des langages XML structurés et réfléchis comme XForms mais aussi XPL, ... cela sans écrire une ligne de Javascript (ou de pseudo-javascript).

Les applications XForms (et par extension Orbeon Forms) permettent donc d’éditer du XML.
Vu que les métadonnées dans ORI-OAI et dans l’échange de métadonnées via le protocole OAI-PMH se rammènent à des fichiers XML, l’utilisation de XForms et Orbeon Forms pour concevoir l’éditeur de métadonnées ORI-OAI est une excellente option.
Celui-ci apporte un certain nombre d’outils permettant de mettre en oeuvre cette édition de fiches de métadonnées :

des XForms pour un certain nombre de schémas de métadonnées et de cas d’utilisation :

formulaire OAI-DC (Dublin core) complet
formulaire LOM complet (conçu avec la société Orbeon qui développe Orbeon Forms),
formulaire LOM simple (formulaire ~auteur)
formulaire LOMFR en préparation (en attente de la sortie officielle du schéma et recommandations du LOMFR)
formulaire SUPLOMFR en préparation (en attente également de la sortie officielle du schéma et recommandations du SUPLOMFR)

des "widgets" qui permettent de faciliter la création de formulaires, c’est à dire d’alléger les XForms notamment dans l’écriture de blocs souvent redondant (conçu avec la société Orbeon qui développe Orbeon Forms)
d’une procédure de sauvegarde/chargement de XForms

soit par via Web Service (en associant un serveur de web service à l’éditeur de métadonnées : dans ORI-OAI, on propose le module de workflow ori-oai-workflow
soit par l’IHM : l’éditeur devient un simple éditeur de métadonnées en ligne qui permet la sauvegarde dur son poste de travail des fiches que l’on édite

d’une procédure permettant le chargement (mise à jour régulière) de vocabulaires via un web service : dans ORI-OAI, on propose le module de vocabulaires ori-oai-vocabulary pour offrir ce service de vocabulaires. Ces vocabulaires sont utilisés dans ORI-OAI-MD-EDITOR au travers des listes de sélection, des auto-complétions, recherche de VCARDs, navigations dans les taxonomies, ...
=> à noter que tout comme pour le workflow, les web services sont constitués simplement d’une ou 2 méthodes avec des types simples en paramètres et en retour (des chaînes de caractères ou des entiers). Il est donc aisé d’implémenter ces Web Services via d’autres applications (Java ou autre) en fonction de vos besoins et donc de connecter ORI-OAI-MD-EDITOR à des outils existants.
Il est possible aussi de modifier simplement côté Orbeon Forms la procédure de chargement/sauvegarde du fichier ou la procédure de chargement des vocabulaires (on peut très simplement par exemple utiliser des vocabulaires locaux à l’applciation Orbeon Forms en modifiant seulement les XForms des formulaires.
d’une procédure permettant d’ajouter de nouveaux formulaires en copiant/collant simplement un formulaire existant.

Pour plus de détails, vous pouvez vous référer à la documentation technique autour de ce module (et de son interaction avec le module ori-oai-workflow et le module ori-oai-vocabulary) :
http://sourcesup.cru.fr/ori-workflow/

ORI-OAI-MD-EDITOR: Tests !

Vous pouvez tester cet éditeur de métadonnées en utilisant par exemple l’instance déployé à Rennes1 (en mode "standalone" / éditeur distant, c’est à dire non connecté au Workflow):
http://ori-oai-workflow.univ-rennes1.fr/md-editor/welcome

Vous pouvez également le tester au travers de la version de démonstration d’ORI-OAI à installer sur un windows :
http://sourcesup.cru.fr/frs/download.php/1746/orioai-demo-quickstart-1.0.0.exe
ou sur un linux/macintosh (disposant d’un JDK1.5 ou supérieur) :
http://sourcesup.cru.fr/frs/download.php/1773/orioai-demo-install.jar
(puis java -jar orioai-demo-install.jar )

Bienvenue sur ce blog dit "professionnel"

Vincent Bonamy — Wed, 19 Dec 2007 17:17:00 +0100

Ceci est un blog professionnel.
Les objectifs de ce blog sont multiples. Principalement, le but est de partager/mutualiser un certain nombre de choses, d’idées, de pratiques autour des sujets que je peux traiter durant mon travail au Centre de Ressources Informatique de Rennes1.
Je travaille autour de ORI-OAI, J2EE, Spring, JSF, Hibernate, Acegi, XML, LOM, OAI-PMH, Python, Zope, Plone (parfois du Ruby), XForms, etc.

Je suis ammené sur mon poste de travail Debian ou sur serveurs, à faire

du développement "propre" (repository subversion, documentation docbook mis à jour en fonction, etc.
du "bricolage" (scripts en tout genre, conversions de données, installation et utilisation de packages, etc.)
de l’exploitation en tout genre (ldap, apache, tomcat, sauvegardesz de bds, etc).

Dans ce blog vous trouverez +/- en vrac des choses autour de cela simplement.

En tout cas, bonne lecture !