Documentation SDX-2 Télécharger Installer Présentation Configuration Indexation Recherche OAI Javadoc Référence API-XSP Migration Configuration Sitemap API-XSP API-URL Schemas Performances | # La configuration d'une application SDX-2 issue d'une application SDX-1 Ce document ne constitue pas la documentation complète concernant la configuration d'une application SDX-2. Nous allons seulement indiquer comment les informations de configuration de SDX-1 doivent être modifiées pour la version 2. En d'autres mots, il s'agit d'un guide qui permet de transformer le fichier de configuration d'une application SDX-1 (`db_info.xml`) en fichier de configuration d'une application SDX-2 (`application.xconf`). Avant de lire ce guide, il est important de lire et comprendre la section de la documentation qui introduit l'architecture de SDX-2. En particulier, il est important de comprendre les notions d' applications , de bases de documents et d' entrepôts de documents . De plus, il pourra être utile de se référer à la documentation complète de la configuration d'une application SDX-2 pour ajouter des paramètres inexistants en SDX-1 et donc non discutés ici. ## Les fichiers impliqués En version 1, la configuration d'une application SDX est contenue dans un document XML qui se situait nécessairement dans un fichier `db_info.xml` situé dans un dossier nommé `conf` qui se situe dans le dossier de l'application. Par exemple, pour une application SDX avec identifiant test, la configuration est dans le fichier `webapps/sdx/test/conf/db_info.xml`. En version 2, la situation est presque la même. En effet, la configuration est toujours contenue dans un document XML ; ce document XML est toujours situé dans le dossier `conf` d'une application, mais il s'appelle maintenant `application.xconf`. Nous devons également souligner que le nom du dossier dans lequel réside une application sous SDX n'a plus besoin de coïncider avec son identifiant, ce qui laisse une certaine souplesse dans le déploiement des applications. ## Identification et configuration Le fichier de configuration d'une application SDX-1 commence de cette manière :
    <sdx:dbInfo code="sdxdoc"
      xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
En SDX-2, cet élément supérieur devient plutôt quelque chose comme :
    <sdx:application
            id="fr.gouv.culture.sdx.sdxworld"
            xml:lang="fr"
            xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
On doit noter ici que l'élément supérieur est maintenant `<sdx:application/>`, que l'attribut `code` a disparu, que l'espace de noms SDX est le même, et que deux nouvelles informations font leur entrée : L'identifiant public de l'application, qui devrait être unique parmi toutes les applications SDX, et c'est pourquoi nous invitons à le définir en utilisant la technique des noms de domaines inversés. Par exemple, pour une application de la DRAC Bretagne, cela pourrait être fr.gouv.culture.drac-bretagne.inventaire. Cet identifiant public est obligatoire, et il permet de rendre les bases facilement réplicables d'une installation à l'autre tout en étant utilisé pour identifier les cibles de recherches multibases. La langue par défaut de l'application, cette langue pouvant être utilisée pour déterminer des analyseurs de mots par défaut, des algorithmes de tri par défaut, des langues d'interface par défaut, etc. Nous conseillons vivement d'indiquer une langue à l'aide de cet attribut, même s'il s'agit d'une application multilingue. Il est possible de spécifier d'autres langues dans différents contextes, celle associée à cet élément est uniquement une langue par défaut. La suite du fichier de configuration SDX-1 est un élément `<sdx:configuration/>` qui contient des informations sur les langues (`<sdx:languages/>`), les locales (`<sdx:locales/>`), la configuration de l'outil de recherche (`<sdx:lucene/>`), les catalogues d'entités externes (`<sdx:catalogs/>`), la transformation d'indexation (`<sdx:extraction/>`), la transformation préliminaire (`<sdx:transformation/>`) ainsi que certains paramètres (`<sdx:parameters/>`). L'élément `<sdx:configuration/>` lui-même n'est plus nécessaire. Nous avons déjà vu comment indiquer la langue par défaut d'une application, les autres méthodes de spécification de langues seront indiquées lorsqu'elles s'appliquent. Les éléments `<sdx:languages/>` et `<sdx:locales/>` ne sont donc plus nécessaires et peuvent être ignorés. La configuration de l'outil de recherche ne se fait plus globalement comme dans SDX-1, c'est pourquoi l'élément `<sdx:lucene/>` n'est plus utile non plus. Son contenu sera réutilisé ailleurs dans la configuration. Les catalogues d'entités externes sont toujours utiles en SDX-2, et leur configuration est presque la même. Le seul changement, c'est l'attribut `file` qui est renommé `src`, par souci de cohérence. Son contenu est une URL relative à l'endroit où se situe le fichier de configuration. On peut insérer l'élément `<sdx:catalogs/>` et ses sous-éléments directement sous `<sdx:application/>`. Les éléments `<sdx:extraction/>` et `<sdx:transformation/>` sont importants car ils indiquent les transformations XSLT à utiliser pour indexer et peut-être transformer préalablement les documents XML dans SDX. En version 2, ces informations sont précisées selon un mécanisme nettement plus puissant appelé pipeline. Ces deux éléments peuvent donc être supprimés. Enfin, les paramètres... TODO. ## Les informations générales Dans la configuration d'une application SDX-1, il était possible de décrire une application en insérant un élément `<sdx:informations/>` et ses sous-éléments. En SDX-2, ces éléments n'existent plus. Toutefois, si vous voulez ajouter toute autre information au document XML de configuration (`application.xconf`), vous pouvez le faire, en autant que vous respectiez ces deux consignes : Utilisez un espace de noms différent de celui de SDX. Ne modifiez pas la hiérarchisation des éléments de l'espace de noms SDX. Par exemple, l'élément `<sdx:catalogs/>` doit être un enfant immédiat de `<sdx:application/>`. Si vous insérez un élément entre les deux, les catalogues seront pas pris en compte. Cette manière de procéder est nettement plus souple. Nous voulons toutefois signaler qu'il est possible que des informations standards de description des applications SDX soient proposées, par exemple en utilisant des métadonnées Dublin Core. ## Les bases de documents, les entrepôts et la recherche La dernière partie de la configuration d'une application SDX-1 concerne les champs de recherche, définis dans un élément `<sdx:fieldList/>`. En SDX-2, cette liste de champs sera aussi présente, mais dans le contexte d'une base de documents (voir l'architecture). Une application SDX-1 est conçue, par définition, avec une seule base de documents et un seul entrepôt, car ces concepts ne sont pas vraiment présents en SDX-1. A tout le moins, le développeur ne peut pas effectuer de choix ou de configuration particulière. Nous allons donc supposer que la migration s'effectue vers une application SDX-2 à une seul base et un seul entrepôt de documents. ### L'entrepôt de documents Les documents XML indexés par SDX-1 sont stockés dans une base de données relationnelle, par exemple MySQL. Cette option peut aussi être choisie en SDX-2, mais elle n'est pas la seule disponible. On peut également choisir un entrepôt système de fichiers ou un entrepôt URL. Cet aspect de la configuration étant inexistant en SDX-1, nous vous invitons à consulter la documentation sur la configuration des entrepôts pour savoir comment effectuer cette partie de la migration. Soulignons toutefois que les documents XML ne pourront pas rester dans votre base relationnelle SDX-1, sauf si vous utilisez un entrepôt URL et que vous mettez en place un outil pour servir ces documents depuis des URL. Cette approche ne permet pas, toutefois, l'ajout de documents par SDX. Vous pouvez donc effectuer votre choix de type et de configuration d'entrepôt sans tenir compte du fait que vous migrez depuis SDX-2. ### La base de documents La configuration de la base de documents sera relativement simple lors d'une migration, car les principales informations sont déjà présentes dans la configuration de l'application en version 1. La documentation de référence concernant la configuration des bases de documents pourra vous être utile si vous voulez aller plus loin. Vous devrez d'abord déterminer un identifiant pour votre base de documents, et normalement votre base (unique) devrait être la base par défaut. Le début de la configuration sera donc semblable à ceci :
    				<sdx:documentBase id="mon_id" type="lucene" default="true">
Ensuite, vous pouvez recopier intégralement l'élément `<sdx:fieldList/>` (et ses sous-éléments) de votre configuration SDX-1 dans votre configuration en version 2. En effet, la définition des champs est totalement compatible. SDX-2 vous offre toutefois plus de souplesse quant à la langue des contenus indexés. En version 1, une seule langue par application était possible. En version 2, chaque champ peut avoir sa propre langue, et donc ses propres outils linguistiques. Bien entendu, dans le contexte d'une migration, tous les champs ont la même langue, alors il est conseillé de la définir au niveau de l'élément `<sdx:fieldList/>`, en y ajoutant un attribut `xml:lang` avec le code de langue approprié. Par exemple :
    <sdx:fieldList xml:lang="fr-CA"/>
Spécifier la langue des champs implique également le choix d'un analyseur de texte pour l'indexation. En SDX-1, c'est l'élément `<sdx:lucene>` qui le précisait, la valeur par défaut étant un analyseur de mots pour le français. En SDX-2, le choix de l'analyseur de mots est une conséquence de la spécification de la langue, sauf indication contraire. Si vous voulez spécifier votre propre classe pour un analyseur, vous devez utiliser l'attribut `analyzerClass` et y mettre le nom complet de la classe Java qui doit nécessairement étendre la classe `fr.gouv.culture.sdx.search.lucene.analysis.Analyzer`. Vous pouvez aussi spécifier un fichier de configuration pour l'analyseur à l'aide de l'attribut `analyzerConf`. Ce fichier de configuration peut être spécifié même si vous ne précisez pas de classe particulière. La configuration d'une base de documents SDX-2 doit aussi inclure un élément `<sdx:index>` qui indique de quelle manière l'indexation se fera. Cet élément contient un élément `<sdx:pipeline>` qui est la définition d'une séquence de transformations XML. Lors d'une migration, cette configuration sera presque toujours faite ainsi :
    <sdx:index>
      <sdx:pipeline>
        <sdx:transformation id="step1" type="xslt" src="indexation.xsl"/>
      </sdx:pipeline>
    </sdx:index>
Dans cette configuration, vous devez indiquer dans l'attribut `src` le chemin vers votre feuille de style d'indexation. TODO : comment ajouter une transformation préalable?
| Auteur : Martin Sévigny ( AJLSM ) - 2002/10/31

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.