Donc, voici le programme :

#!/usr/bin/env perl

use strict;
use warnings;

use CQL::Parser;
use GraphViz;
use Term::ANSIColor;
use UNIVERSAL;

my $query    = shift;
my $filename = shift;

my $root;

eval { $root = CQL::Parser->new()->parse($query) };
if ($@) {
    die colored(['red'], "We've got some problems: $@"), $/;
}

my $gv = GraphViz->new( layout => 'dot', node => { shape => 'box' } );

traverse( $root, $gv );

open my $fh, '>', $filename;
print $fh $gv->as_png();
close $fh;

sub traverse {
    my ( $node, $gv, $parent ) = @_;

    if ( $node->isa('CQL::BooleanNode') ) {
        $gv->add_node( $node, label => $node->op );
        traverse( $node->left(),  $gv, $node );
        traverse( $node->right(), $gv, $node );
        $gv->add_edge( $parent => $node ) if defined $parent;
    }
    elsif ( $node->isa('CQL::TermNode') ) {
        if ( defined $node->getQualifier ) {
            $gv->add_node( $node->getQualifier, label => $node->getQualifier );
            $gv->add_node( $node->getRelation,
                label => $node->getRelation()->getBase() );
            $gv->add_node( $node, label => $node->getTerm() );
            $gv->add_edge( $node->getQualifier => $node->getRelation );
            $gv->add_edge( $node->getQualifier => $node );
            $gv->add_edge( $parent => $node->getQualifier ) if defined $parent;
        }
        else {
            $gv->add_node( $node, label => $node->getTerm() );
            $gv->add_edge( $parent => $node ) if defined $parent;
        }
    }
    else {
        print colored['green'], ref($node), $/; # cela m'aide à découvrir ce qui n'est pas actuellement géré par la fonction traverse()
    }
}

Le but du programme était juste de me refamiliariser avec le parcours d'arbre, et donc, il n'exploite probablement pas toutes les subtilités de l'analyse de CQL::Parser.

Voici quelques exemples de requêtes et des arbres correspondants :

Bon, ce n'est pas grand chose, mais cela m'a déjà permis de lire le code de CQL::Parser et de réfléchir succinctement à la structure de données créée par ce dernier.

Hier, cette gymnastique a commencé par une réflexion sur l'analyse de requêtes telles que celles soumises à un moteur de recherche et la soumission de ces dernières à un moteur SQL. Bon, le sujet étant assez vaste, je me suis d'abord intéressé à l'analyse syntaxique d'une requête. J'ai été tout naturellement sur le CPAN pour voir les modules existants, et ainsi lire les implémentations actuelles. Je me suis penché plus particulièrement sur deux modules :

1. Search::QueryParser écrit par Laurent Dami, et
2. CQL::Parser écrit par Brian Cassidy.

Ces deux modules analysent tout les deux des requêtes, mais la forme des requêtes est différentes, le premier analyse des requêtes « à la Google » et le second est spécialisé dans les requêtes CQL (CQL signifiant Common Query Language). Les détails d'implémentation sont également différents :

• Search::QueryParser n'utilise pas de tokenizer externe et travaille donc de la manière suivante : une boucle dont le paramètre est la requête, et des appels successifs à s/// permet de raccourcir cette requête jusqu'à son analyse complète. J'aime bien cette approche pour construire rapidement un analyseur syntaxique de requêtes simples. Par contre, quand le langage de requête devient plus complexe, je crains que cela ne devienne un peu laborieux à maintenir ;
• CQL::Parser quant à lui s'appuie sur un tokenizer externe : String::Tokenizer. Ce dernier traduit une chaîne de caractères en un tableau, il « suffira » de traduire ce tableau de manière à interroger le système d'information de notre choix (SGBD, moteur de recherche, etc) ; j'ai lu rapidement la documentation de String::Tokenizer, et c'est définitivement un module que je rajouterai dans mon Top 100.

Du côté de l'implémentation naïve, j'ai essentiellement joué avec la méthode adoptée par Search::QueryParser. Je me suis contenté de créer un arbre d'une expression arithmétique. Et c'est tellement naïf que je n'ai même pas valider l'expression arithmétique. Au niveau de la création de l'arbre, j'ai utilisé un autre module de mon Top 100, à savoir Tree::DAG_Node. Voici le code produit :

#!/usr/bin/env perl

use strict;
use warnings;
use diagnostics;

use Tree::DAG_Node;

my $query = shift || '+ 1 2';
my $root;
my $lastnode;

while ($query) {
    if ($query =~ s/^(\+)\s*(\w*)/$2/) {
        if (not defined $root) {
            $root = Tree::DAG_Node->new();
            $root->name( $1 );
            $lastnode = $root;
        } else {
            my $node = Tree::DAG_Node->new();
            $node->name( $1 );
            $lastnode->add_daughter( $node );
            $lastnode = $node;
        }
    } elsif ($query =~ s/^(\d+)\s*(\w*)/$2/) {
        my $daughter = $lastnode->new_daughter;
        $daughter->name( $1 );
    }
}


my $diagram = $root->draw_ascii_tree;
print map "$_\n", @$diagram;

Il reste encore du chemin avant de traduire un

dc.title any rose and dc.creator = eco

en

SELECT * FROM books WHERE books.title LIKE '%rose%' and author LIKE '%eco%'

Mais chaque chose en son temps, et le CPAN est plein de modules qui me serviront de boussole pour terminer cette promenade.

Avant de passer aux outils proprement dit, voici le cadre dans lequel ils ont été développés. Dans le cadre d'une formation organisée conjointement par l'Université Libre de Bruxelles (ULB) et par la Commission Universitaire pour le Développement (CUD). j'ai donné un cours nommé « Systèmes intégrés de gestion de bibliothèques ». Les stagiaires suivant cette formation devaient mener un projet, et un de ces stagiaires souhaitait migrer de Winisis vers Koha (c'était le logiciel servant d'illustration à mon cours). Je me suis donc penché sur la question. L'objectif était donc de migrer la base de données ISIS vers du MARC21.

Les bases de données s'appuyant sur un schéma spécifique à chaque utilisateur (Winisis n'est donc pas un SIGB, mais un SGBD, spécialisé dans les données bibliographiques, certes, mais un SGBD ; il ressemble donc plus à Microsoft Access qu'à Koha). la première étape consiste donc à déterminer la structure de la base de données de manière à établir une table de correspondance vers le format MARC souhaité (MARC21, Unimarc ou n'importe quelle autre variante). Aujourd'hui, je ne verrai que cette étape, et l'outil développé pour cela. Les autres étapes suivront dans les jours à venir.

La structure d'une base de données ISIS, nommé « Field Definition Table », donc « table de définition des champs », dans le jargon ISIS se trouve stocké dans un fichier texte dont l'extension est « .fdt ». En analysant ce fichier, on peut donc facilement déterminer la structure de la base de données. Biblio::Isis est le module de choix pour manipuler les bases de données ISIS, il offre une fonction permettant de lire cette table de définition des champs, et donc le code suivant est basé sur ce module :

#!/usr/bin/env perl

use strict;
use warnings;

use Getopt::Long;
use File::Find::Rule;
use Data::Dumper;
use Encode qw( from_to );
use Spreadsheet::WriteExcel;

my $config = {};

my %save_functions = (
    excel => \&_save_excel,
    dump  => \&_dump_struct,
);

my $fdt_struct = {};

GetOptions( $config, 'database=s', 'file=s', 'save=s' );

if ( not exists $config->{database} and not exists $config->{file} ) {
    die _usage();
}
else {
    my $fdt_file;
    if ( exists $config->{database} ) {
        $fdt_file = _get_fdt_file( $config->{database} );
    }
    else {
        $fdt_file = $config->{file};
    }
    $fdt_struct = _map_fdt_file($fdt_file);
    _print_fdt_struct($fdt_struct);
    _save_fdt_struct( $config->{save}, @ARGV ) if $config->{save};
}

sub _usage {
    return
"Usage: $0 [--database 'ISIS database' | --file 'ISIS.FDT' [--save excel|dump filename.xls]]\n";
}

sub _get_fdt_file {
    my $database = shift;

    if ( not -e $config->{database} ) {
        print "Unable to open the ISIS database: $database\n";
        return;
    }

    my @files =
      File::Find::Rule->file()->name( '*.fdt', '*.FDT' )
      ->in( $config->{database} );

    if ( scalar(@files) > 1 ) {
        print "Too many FDT files!\n";
        return shift(@files);
    }

    if ( scalar(@files) == 0 ) {
        print "No FDT files!!!\n";
        return;
    }

    return shift(@files);
}

sub _map_fdt_file {
    my $fdt_file = shift;

    my $fdt_struct = {};

    # Code heavily based on Biblio::Isis
    my $fieldzone = 0;

    open( my $fileFDT, $fdt_file ) or die "$fdt_file: $!\n";
    binmode($fileFDT);

    while (<$fileFDT>) {
        chomp;
        if ($fieldzone) {
            my $name       = substr( $_, 0,  30 );
            my $tag        = substr( $_, 50, 3 );
            my $repeatable = substr( $_, 61, 1 );

            $name =~ s/\s+$//;
            $tag  =~ s/\s+$//;

            $fdt_struct->{$tag} = {
                name       => from_to( $name, 'cp850', 'utf8' ),
                repeatable => $repeatable,
            };
        }

        if (/^\*\*\*/) {
            $fieldzone = 1;
        }
    }

    close($fileFDT);

    return $fdt_struct;
}

sub _print_fdt_struct {
    my $fdt_struct = shift;

    foreach my $tag ( keys %{$fdt_struct} ) {
        print "$tag\t=>\t" . $fdt_struct->{$tag}->{name} . "\n";
    }

    return;
}

sub _save_fdt_struct {
    my $save_function = shift;

    if ( exists $save_functions{$save_function} ) {
        if ( scalar(@_) > 0 ) {
            $save_functions{$save_function}->(@_);
        }
        else {
            die "No file where to put the schema\n";
        }
    }
    else {
        die "Save function <$save_function> doesn't exist\n";
    }
}

sub _save_excel {
    my $excel_filename = shift;

    my $excel = Spreadsheet::WriteExcel->new($excel_filename);
    my $ws    = $excel->add_worksheet();
    $ws->write( 0, 0, "Champ ISIS" );
    $ws->write( 0, 1, "Champ MARC21" );
    $ws->write( 0, 2, "Description" );

    my $row = 1;
    foreach my $tag ( sort keys %{$fdt_struct} ) {
        $ws->write( $row, 0, $tag );
        $ws->write( $row, 2,
            from_to( $fdt_struct->{$tag}->{name}, 'utf8', 'latin1' ) );

        $row++;
    }
}

sub _dump_struct {
    print Dumper $fdt_struct;
}

L'outil permet donc d'afficher la structure d'une base de données, mais aussi de créer un fichier Excel contenant cette structure. C'est ce fichier Excel qui servira de base de à la négociation pour mettre en place la table de correspondance nécessaire pour lancer la migration.

L'outil s'emploit de la manière suivante : ./fdt_reader.pl -f ISIS.FDT -s excel isis_db.xls. Le fichier isis_db.xls contient trois colonnes :

1. la première est le champ ISIS ;
2. la deuxième est le champ (et le sous-champs) MARC correspondant ;
3. la troisième est la description associée au champs ISIS, et donc, sur base de cette description, on se fait une idée précise de la fonction de celui-ci.

Nous verrons la prochaine fois comment ce fichier Excel s'intègre dans le processus de migration.