Ajout d'une nouvelle fonctionnalité concernant les utilisateurs : SDX gère maintenant la notion de groupes d'utilisateurs. Un utilisateur peut faire partie d'un ou plusieurs groupes, mais peut aussi ne pas être associé à aucun groupe. Cette gestion est maintenant assurée par une nouvelle interface Web, et l'approche utilisée est décrite par ailleurs.

Cette nouvelle fonctionnalité demande d'effectuer un changement dans la structure de la base de données. Les requêtes suivantes doivent être effecutées :

CREATE TABLE sdx_group
  (db VARCHAR(100) NOT NULL,
  name VARCHAR(255) NOT NULL,
  description VARCHAR(255),
  PRIMARY KEY(db, name));
CREATE TABLE sdx_user_group
  (db VARCHAR(100) NOT NULL,
  user VARCHAR(50) NOT NULL,
  gr VARCHAR(255) NOT NULL,
  ty CHAR(1) NOT NULL,
  PRIMARY KEY (db, user, gr, ty));

Pour accompagner cette gestion des groupes, l'API XSP a été modifiée et le format XML des utilisateurs.

Correction d'un bogue qui faisait en sorte que les informations sur les filtres n'étaient pas sortis pour une liste de termes.

Le fichier de configuration permet maintenant de spécifier si les noms de champs doivent respecter la casse (par défaut) ou non (attribute ignoreCase de l'élément fieldList du fichier db_info.xml.

Correction de quelques problèmes reliés au nombre de résultats par page de résultats. Maintenant, autant pour les termes d'une liste que pour une recherche, on peut donner un nombre de résultats par page de 0 pour indiquer de ne pas retourner de résultats. Si on donne un nombre positif, ce nombre de résultats par page est appliqué. Si on donne un nombre négatif, tous les résultats sont retournés. Enfin, si on ne spécifie rien, la valeur par défaut (20) est utilisée. Ces remarques sont valables pour les trois API de SDX.

Correction d'un problème interne affectant les résultats de la servlet users.

L'ajout d'un document XML peut se faire depuis un champ d'un formulaire HTML à l'aide de l'attribut formParam de l'élément sdx:uploadDocument dans l'API XSP.

Quelques modifications internes pour améliorer (nettement) les performances reliées aux requêtes avec un grand nombre de résultats. Si le tri de pertinence est choisi (par défaut), les données ne sont récupérées qu'à la demande, ce qui réduit les besoins en mémoire. Lorsque les données doivent triées, la situation n'a pas changé. Ces modifications n'impliquent que l'API Java, car deux méthodes publiques de la classe fr.gouv.culture.sdx.query.SortSpecification ont été supprimées.

SDX utilise maintenant la version 6.4.4 du processeur XSLT Saxon. Pour que vos applications fonctionnent correctement, vous devez faire une modification à votre fichier cocoon.properties. Repérez l'endroit où se trouve la ligne :

transformer.factory.sourceParserClass = fr.gouv.culture.sdx.utils.CatalogSAXParser

et ajoutez sous cette dernière la ligne suivante :

transformer.factory.styleParserClass = fr.gouv.culture.sdx.utils.CatalogSAXParser

Le nouveau fichier cocoon.properties livré avec SDX 1.1 tient compte de ce changement.

Ajout de la possibilité de spécifier l'emplacement d'un document attaché via une URL, soit relative au document XML soit absolue. L'attribut url de l'élément sdx:attachedDocument lors de l'indexation précise cette URL. A noter que cela devient la méthodé privilégiée pour spécifier le document attaché.

Une nouvelle information d'environnement est fournie par SDX à l'aide de l'élément sdx:server que l'on trouve dans sdx:environment. L'attribut url contient l'adresse URL de l'installation SDX en cours. On pourra avoir, par exemple :

<sdx:document>
  <sdx:environment>
    <sdx:server url="http://sdx.culture.fr/sdx"/>
...

On peut maintenant spécifier le nombre de documents à charger à la fois dans SDX, à l'aide d'un élément sdx:parameter dans le fichier de configuration.

Correction d'un bogue qui empêchait l'utilisation de l'élément sdx:deleteDocument de l'API XSP.