Brevet FR2871258A1 — publié le 20051209

GENERATEUR D'INTERFACES POUR SYSTEMES D'ACCES A DES DONNEES La présente invention concerne un générateur d'interfaces pour systèmes d'accès à des données, destiné à fournir une première interface d'accès par navigation dans une arborescence et une deuxième interface d'accès par saisie. D'une manière générale, l'invention trouve une application avantageuse dans le domaine de la conception automatique d'interfaces homme-machine permettant d'accéder à des données. Plus particulièrement, l'invention porte sur la génération d'interfaces de recherche de données présentant un paramétrage simple sans nécessiter de io re-compilation de codes sources. Il existe aujourd'hui divers moyens permettant à un utilisateur d'accéder à des données, parmi lesquels on peut citer: - les systèmes de paramétrage de la navigation dans un service Web mis en oeuvre le plus souvent dans des outils de multi-publication: o Websphere Transcoding Publisher (WTP) d'IBM o Cocoon de la communauté Apache o Wokup - les normes de description XML de formulaires de recherche (notamment la norme XForms du W3C). - les composants génériques paramétrables permettant d'accéder à des sources de données hétérogènes: o la technologie de Sun JDBC o la technologie des drivers ODBC de Microsoft - les procédés pour créer des pages dynamiquement: - côté client: o DHTML (Dynamic HTML) côté serveur: o Les JSP (JavaServer Pages) de Sun o PHP Ces moyens connus de génération d'interfaces pour systèmes d'accès à des données sont destinés à fournir une première interface par navigation dans une arborescence de rubriques et sous-rubriques et/ou une deuxième interface d'accès par saisie dans un formulaire approprié. Des passages sont possibles entre un noeud terminal de liaison de la première interface et la deuxième interface de saisie. io On remarquera toutefois que ces systèmes d'interfaçage ne sont pas bien adaptés à une navigation sur des terminaux tels que téléphones mobiles ou assistants personnels, dont l'écran de petite taille ne permet d'afficher que des arborescences d'étendue limitée, ceci d'autant plus qu'elles doivent souvent être couplées à des formulaires de saisie également consommateurs is de surface écran. Le schéma de navigation classique est alors habituellement le suivant: o Arrivée sur l'accueil de l'interface o Sélection d'une rubrique o Sélection d'une ou plusieurs sous-rubriques pour affiner sa recherche o Saisie du ou des critères de recherche via une interface de saisie, formulaire de saisie par exemple, pour trouver une information en lien avec la sous-rubrique demandée o Production du résultat présentant une liste d'items correspondant aux critères demandés o Sélection d'un item parmi N pour avoir plus de détails sur celui-ci Ces générateurs d'interfaces connus ne proposent donc pas de système de paramétrage de navigation ré-utilisable facilement afin de concevoir de nouveaux services à partir de ce qui a déjà été mis en place sur d'autres services, alors que le schéma de navigation pour un accès de données est pourtant souvent le même pour ce type de terminaux. 25 Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un générateur d'interfaces pour systèmes d'accès à des données, destiné à fournir une première interface d'accès par navigation dans une arborescence et une deuxième interface d'accès par saisie, ladite arborescence présentant au moins un noeud terminal de liaison à ladite deuxième interface, qui permettrait de décorréler le mode d'accès aux données recherchées à travers l'arborescence de ladite première interface du mode d'accès de recherche multicritères par saisie de ladite deuxième interface. io La solution au problème technique posé consiste, selon la présente invention, en ce que ledit générateur d'interfaces comprend, au moins: un module de traitement de la navigation, apte à fournir ladite première interface, - un module de traitement de scripts de saisie, apte à fournir la deuxième 15 interface, chaque script étant défini, au moins, par les champs de configuration suivants: * un identifiant unique, * un identifiant d'un programme d'accès à une source de données, associé à au moins un paramètre d'identification du type de données à 20 accéder dans ladite source, * une liste de critères de saisie, ledit noeud terminal de liaison de l'arborescence de navigation étant rattaché à un script de la deuxième interface par ledit identifiant unique de script. Ainsi, du fait du rattachement direct des noeuds terminaux de liaison aux scripts correspondants par l'intermédiaire de l'identifiant unique, le générateur d'interfaces selon l'invention permet l'assemblage simple, dans une arborescence de navigation, de scripts d'accès de données multicritères ainsi que le paramétrage de ces scripts. Il en résulte que pour un type d'information donné, c'est à dire une source de données particulière, le même processus de recherche multicritères pourra être utilisé pour des services différents ayant un système de rubriques par arborescence différent, adapté au public visé et à l'objectif qui a été fixé par chaque service. Cet avantage est particulièrement sensible dans le cas de la conception d'un nouveau service lorsque les sources de données changent ou que le service est destiné à une nouvelle cible cliente ou encore que l'agencement des rubriques change. En résumé, l'invention offre par rapport aux systèmes existants la possibilité de lier simplement des scripts d'accès à l'arborescence de navigation dans l'interface. Cela permet entre autre: - de changer de fournisseur de contenus sans pour autant toucher à l'agencement des rubriques du service, ro - de changer l'intitulé d'une rubrique ou sa place dans le service sans pour autant affecter les méthodes d'accès aux données, - de ré-utiliser facilement le script d'accès à des données mis en oeuvre dans un service déjà existant pour proposer une recherche sur les mêmes données dans un autre service. is Selon l'invention, ledit module de traitement de scripts est apte à générer un formulaire de saisie associé à ladite liste de critères de saisie. Comme on le verra plus loin, la génération ou non d'un formulaire de saisie par le module de traitement des scripts dépend du type d'interface demandée en sortie de l'arborescence au niveau d'un noeud terminal de liaison. L'invention est donc bien adaptée aux terminaux possédant un écran de petite taille car l'agencement d'interfaces proposé n'exige la présentation simultanée à l'écran que d'un nombre limité d'informations. On ajoutera également que le mode de navigation par arborescence limite l'utilisation du clavier dont l'usage est en général mal commode sur ces terminaux. Dans le même ordre d'idée, il faut signaler que l'invention peut également être appliquée dans le domaine vocal avec une première interface par guide vocal au sein de rubriques et une deuxième interface de saisie par reconnaissance vocale. Un autre aspect du générateur d'interfaces conforme à l'invention 30 consiste en ce qu'il comprend en outre un module de traduction, apte à fournir un intitulé dans une langue donnée pour: - chaque rubrique associée à chaque noeud de l'arborescence de navigation, - chaque critère de saisie de chaque script, - des valeurs présélectionnées de critères de saisie de chaque script. A cet effet, l'invention prévoit que le module de traduction comprend une base d'intitulés associée à chaque langue, chaque intitulé étant identifié par un identifiant unique commun à toutes les bases d'intitulés. En particulier, selon l'invention, ledit identifiant unique commun est associé à chaque noeud de l'arborescence de navigation pour un intitulé concernant les diverses rubriques de l'arborescence, ou bien ledit identifiant unique commun est associé à chaque script de saisie pour des intitulés relatifs aux critères de saisie ou à leurs valeurs présélectionnés. io Ainsi, on comprend que le générateur d'interfaces, objet de l'invention, présente par rapport aux systèmes existants les avantages, d'une part, de lier automatiquement l'arborescence de navigation dans la première interface à un système de traduction multilingue des intitulés de chaque rubrique et, d'autre part, de lier automatiquement la description dans les scripts des critères de recherche à un système de traduction multilingue des intitulés de chaque critère et des valeurs qu'il peut prendre. La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 est un schéma d'un générateur d'interfaces conforme à l'invention. La figure 2 est un schéma fonctionnel de construction de l'arborescence des rubriques d'une interface de navigation. La figure 3 est un schéma fonctionnel de construction des formulaires 25 associés aux scripts d'une interface de saisie. La figure 4 est un schéma d'arborescence par rubriques pour un service touristique. La figure 5 est un schéma de sous-rubriques associées à la rubrique Adresses utiles du schéma de la figure 4. La figure 6 est une page obtenue après sélection d'une rubrique En journée dans une arborescence. La figure 7 est une page de formulaire de saisie. La figure 8 est une page de réponses à un formulaire de saisie. La figure 9 est une page contenant des renvois à des scripts de saisie. La figure 10 est une page de formulaire de saisie associée à la page de la figure 9. La figure 11 est une page de formulaire avec prise en compte de la 5 langue utilisée par un utilisateur. La figure 12 indique les valeurs possibles pour le champ Budget dans le formulaire de la figure 11. Sur la figure 1 est représenté de manière schématique un générateur d'interfaces pour un système d'accès à des données ou informations. Ce générateur d'interfaces a pour fonction de fournir une première interface sous forme d'arborescence de navigation et une deuxième interface associant à chaque noeud de cette arborescence des scripts d'accès à des sources prédéterminées desdites données. Plus précisément, l'invention propose un mécanisme de liaison entre la description arborescente de la navigation et lesdits scripts d'accès. En se référant à la figure 1, les étapes de la mise en oeuvre du générateur d'interfaces conforme à l'invention se déroulent de la manière suivante: 1 - le terminal active le générateur d'interfaces en sélectionnant une rubrique de l'arborescence de navigation. 2 - le module de traitement de la navigation cherche la position de l'entrée concernant cette rubrique dans la description arborescente stockée en base de données. 3 - l'entrée concernant la rubrique ne possède pas d'entrée fille dans l'arborescence de navigation et n'a pas de lien vers une ressource statique autre qu'un script, alors il s'agit d'un noeud terminal de liaison. 3bis- l'entrée concernant la rubrique possède au moins une entrée fille dans l'arborescence de navigation, cette rubrique doit donc proposer une liste de sous-rubriques. La liste des identifiants de ces sous-rubriques est envoyée au module de traduction, en vue de traduire leurs intitulés dans la langue de l'utilisateur. 4- le module de traitement des scripts de saisie récupère le script demandé et analyse les critères de recherche proposés pour l'accès aux données ainsi que les modes d'accès pour ce script. En fonction du type d'interface demandée par le terminal, le module: - se sert du paramétrage des critères de recherche du script pour générer une interface de saisie, ou formulaire multicritères, non encore traduite, se sert du paramétrage du script pour interroger directement la source de données avec les critères renseignés par l'utilisateur dans les rubriques de io l'arborescence et renvoyer une liste de résultats. Il faut noter que le type d'interface demandée par le terminal (interface de saisie ou liste de résultat) est relayé par le module de traitement de la navigation au module de traitement des scripts. - le module de traduction reçoit du module de traitement des scripts des interfaces proches de ce que va recevoir le terminal mais dont certaines ressources linguistiques (noms et valeurs des critères) n'ont pas encore été traduites dans la langue de l'utilisateur. 6 - le module de traduction récupère dans le dictionnaire adapté à la langue de l'utilisateur les ressources linguistiques nécessaires au rendu final de l'interface et insère la valeur traduite de chaque intitulé dans le flux reçu en entrée du module. 7 - le terminal reçoit du module de traduction une version traduite de l'interface et réalise le rendu final de celle-ci (affichage ou rendu vocal). La première interface: l'arborescence de navigation L'arborescence de navigation dans le générateur d'interfaces selon l'invention s'exprime en terme de rubriques et de sous-rubriques, chaque rubrique ou sous-rubrique étant représentée par une entrée appelée noeud stockée dans une base de données associée au module de traitement de la navigation. Cette base de données contient donc un ensemble de noeuds reliés les uns aux autres de manière arborescente, chaque noeud contenant obligatoirement un identifiant. Cet identifiant n'est pas nécessairement unique puisqu'une même rubrique peut apparaître à plusieurs endroits dans l'arborescence de l'interface. Une même valeur de l'identifiant peut donc être utilisée à plusieurs noeuds de l'arborescence. Un noeud possédant des noeuds filles est appelé branche et contient donc une liste de sous-rubriques à proposer à l'utilisateur dans l'interface lorsque celui-ci sélectionne la rubrique en question. Un noeud ne possédant pas de noeuds filles est appelé feuille et peut être rattaché à un des scripts décrits dans l'étape précédente permettant l'accès aux données cherchées via une interface de saisie, suivant un ou plusieurs critères de recherche. II s'agit alors d'un noeud terminal de liaison à un script. II n'est pas possible de rattacher à un script un noeud de l'arborescence ayant des noeuds filles car le rattachement à un script amène l'utilisateur sur une interface de saisie multicritères qui ne propose par conséquent plus de naviguer dans d'autres sous-rubriques. II faut noter que tous les noeuds de type feuille ne sont pas forcément liés à un script et ne sont donc pas des noeuds terminaux de liaison à un script. En effet, l'aboutissement d'une navigation dans une liste de rubriques et sous-rubriques n'est pas toujours une interface de saisie multicritères. II peut s'agir par exemple d'un lien simple vers une information statique: page de présentation, flux audio pré-enregistré, image, ... La deuxième interface: les scripts de saisie Il s'agit des scripts d'accès à des sources de données. Chaque script permet d'accéder à un type de données particulier (news, restaurants, ...) suivant un ou plusieurs critères (localisation, prix, horaires, ...). Ces scripts sont stockés de préférence dans une base de données spécifique. Un même script d'accès peut être utilisable à plusieurs endroits dans l'arborescence de l'interface qui vient d'être décrite plus haut. Un script possède au minimum les champs de configuration suivant: 30 - un identifiant unique, - un identifiant d'un programme d'accès à une source de données du fournisseur (classe Java, script CGI, ...), - une liste de critères de saisie qu'il faut activer et proposer à l'utilisateur pour ce type de données (localisation, prix, horaires, note d'évaluation, ...) via une interface de saisie (formulaire, reconnaissance vocale, ...). Chaque critère est représenté par un identifiant unique, que le fournisseur de contenu sait a priori gérer dans son programme d'accès. Un même critère peut être utilisé pour plusieurs types de données: par exemple, le critère de prix peut servir à trouver aussi bien un hôtel qu'un restaurant dans une base de données. Certains critères peuvent prendre n'importe quelle valeur (saisie libre) io tandis que d'autres ne peuvent prendre qu'un nombre fini de valeur prédéterminées. Un script peut également contenir les champs de configuration optionnels suivants: - un identifiant de la source de données, - le nom de ladite source, - un ou plusieurs paramètres pré-réglés sous la forme nom du paramètre + valeur du paramètre que le programme d'accès sait interpréter. II peut s'agir par exemple de l'identifiant de la table à parcourir dans une base de données contenant plusieurs tables, - la liste des types de données à fournir dans la liste de réponses obtenues pour la recherche (prix, localisation, ..., chaque type d'information étant représenté par un identifiant unique, - la liste des types de données à fournir dans la fiche détaillée d'un item de la liste de réponses obtenues après la recherche (prix, localisation, Chaque type d'information est représenté par un identifiant unique. La liaison entre l'arborescence et les scripts Lorsqu'un noeud de l'arborescence ne possède pas de noeud fille, cela peut signifier que la rubrique concernée doit être liée à un des scripts disponibles permettant l'accès aux données cherchées via une interface de saisie suivant un ou plusieurs critères de recherche. 2871258 io Ce processus est mis en oeuvre pour certains noeuds terminaux de l'arborescence appelés feuilles de l'arbre de navigation, ou noeuds terminaux de liaison, car ils mettent fin au système de navigation dans les rubriques/sous-rubriques en proposant à l'utilisateur une interface de saisie s qui va lui permettre finalement de trouver l'information précise qu'il recherche. Le lien entre la rubrique et le script se fait via la valeur de l'identifiant du noeud représentant la rubrique et la valeur de l'identifiant unique du script qui doivent être strictement identiques. C'est le générateur d'interfaces qui vérifie via le module de traitement io des scripts, pour chaque noeud feuille de l'arborescence de navigation, s'il existe un script ayant le même identifiant. Si c'est le cas, lorsque l'utilisateur demande à entrer dans la rubrique attachée au script, il génère automatiquement l'interface de saisie multicritères construite en fonction du paramétrage du script. Avec ce mécanisme, un même script peut être utilisé une ou plusieurs fois dans une seule ou plusieurs interfaces de recherche de données multicritères. Autrement dit, la partie navigation dans l'interface est bien séparée de la partie saisie des critères et accès aux données cherchées, conformément à un but recherché par l'invention. Le module de traduction Le module de traduction a pour fonction de gérer les ressources linguistiques qui sont mises en oeuvre pour une langue donnée dans le générateur d'interfaces conforme à l'invention. On appelle ressource linguistique toute donnée textuelle utilisée dans le générateur d'interfaces et qui est à traduire dans une langue compréhensible par l'utilisateur. De façon pratique, ces ressources linguistiques sont essentiellement des intitulés apparaissant soit dans les rubriques de l'arborescence, soit dans les formulaires de saisie fournis par le module de traitement des scripts. Pour chaque langue, on décrit donc dans un dictionnaire un catalogue de ressources linguistiques, chaque ressource contenant au minimum: 2871258 Il - un identifiant unique (ASCII et donc international) permettant une exploitation de la ressource indépendamment de la langue utilisée, - un texte dans la dite langue. L'identifiant d'une ressource linguistique est unique dans le dictionnaire d'une langue donnée mais il est le même entre le dictionnaire d'une langue A et celui d'une langue B puisque c'est au moyen de cet identifiant que l'on peut obtenir la traduction d'un texte d'une langue à l'autre. Ce mécanisme d'identification des ressources linguistiques permet ensuite de mettre en oeuvre ces ressources dans le générateur d'interfaces io sans se préoccuper de la langue utilisée. L'identifiant d'une ressource linguistique n'est pas choisi de manière aléatoire mais contient en lui même une information qui permet par la suite de construire l'interface. Par conséquent, il existe un système de dénomination précis des identifiants suivant l'usage auquel est destinée la ressource ls linguistique. Ce système de dénomination des identifiants est précisé dans la suite. La liaison entre l'arborescence et les ressources linguistiques L'identifiant de chaque noeud de l'arborescence représentant une 20 rubrique permet de trouver dans les dictionnaires l'intitulé à afficher pour cette rubrique dans le générateur d'interfaces. Si l'identifiant de la rubrique dans l'arborescence est rubriqueld , l'intitulé de cette rubrique doit pouvoir être trouvé dans une ressource linguistique dont l'identifiant est rubriqueld.title dans le dictionnaire de la langue courante. S'il n'existe aucune ressource linguistique ayant l'identifiant cherché, on utilise comme intitulé de la rubrique dans la première interface l'identifiant rubriqueld.title . Ce mécanisme permet au concepteur de l'interface de s'apercevoir rapidement que la ressource linguistique en question n'a pas encore été traduite dans une langue donnée. La liaison entre les scripts et les ressources linquistiques Pour chaque script, un certain nombre de critères de recherche sont activés, c'est à dire qu'ils doivent être proposés à l'utilisateur via une interface de saisie (formulaire, reconnaissance vocale, ...). Comme déjà mentionné plus haut, certains critères peuvent prendre 5 n'importe quelle valeur (saisie libre) tandis que d'autres ne peuvent prendre qu'un nombre fini de valeurs pré-déterminées. Pour générer cette interface de saisie, le générateur d'interfaces a besoin au minimum des intitulés suivants: - le nom de chaque critère à proposer dans l'interface de saisie, - les valeurs possibles que peut prendre chaque critère lorsqu'il s'agit d'un critère dont les valeurs possibles sont pré-définies. II existe donc un mécanisme permettant au générateur d'interfaces de récupérer ces ressources linguistiques dans le dictionnaire de la langue de l'utilisateur. Pour un script dont l'identifiant vaut scriptld , proposant un critère de recherche dont l'identifiant est criteriald , le mécanisme de liaison avec le dictionnaire est le suivant: o le nom du critère est obtenu en cherchant dans le dictionnaire de la langue courante une ressource linguistique dont l'identifiant est field.criteriald.scriptld , o la liste des intitulés des valeurs possibles prises par le critère est obtenue en cherchant toutes les ressources linguistiques dont l'identifiant est du type field.criteriald.scriptld. où contient la valeur qui sera envoyée au générateur d'interface après validation de l'interface de saisie par l'utilisateur. Lorsque le générateur d'interfaces ne trouve aucune ressource linguistique ayant ce type d'identifiant, il en déduit automatiquement qu'il s'agit d'un critère à saisie libre et non pas d'un critère avec un nombre fini de valeusr possibles. L'invention va maintenant être décrite de manière détaillée dans l'exemple d'un guide touristique multilingue, multivilles sur terminaux mobiles. L'objectif de ce service est de permettre à un touriste de trouver un Point d'Intérêt (POI) ou un Evènement suivant une recherche multicritères après avoir sélectionné une rubrique et une ou plusieurs sousrubriques. s Le générateur d'interfaces utilisé dans ce but prend en compte au démarrage trois fichiers de configuration XML qui sont décrits dans les paragraphes suivants avec quelques exemples d'utilisation: - le fichier service tree.xml: contient une description de l'arborescence du service (au sens de la navigation) en indiquant à quel moment de la navigation les scripts d'accès aux données sont mis en oeuvre par le biais d'un formulaire de recherche. - le fichier data.xml: contient l'ensemble du paramétrage des scripts d'accès aux sources de données. Chaque script permet l'accès à une source de données locale ou distante suivant un ou plusieurs critères de recherche. - les fichiers dictionnaires messages_ .xml: contiennent chacun dans leur langue la liste de ressources linguistiques utilisées dans le service que ce soit pour donner un intitulé aux rubriques ou pour mettre en oeuvre dans la bonne langue les scripts définis dans le fichier data. xml. A partir de ces descriptions XML, le générateur d'interfaces est capable de générer automatiquement l'enchaînement des pages listant les rubriques et sous-rubriques disponibles dans le service, jusqu'à l'aboutissement à un formulaire de recherche d'un type d'information précis (restaurants, distributeurs de billets, ...). Le fichier service tree.xml définit la liste des rubriques et des sousrubriques contenues dans chaque rubrique. A partir de ce fichier et du fichier dictionnaire, le générateur d'interfaces est capable de générer les pages correspondantes dans la langue de l'utilisateur en suivant le processus représenté sur la figure 2. Lorsque dans le fichier service tree.xml un élément terminal de l'arbre de navigation, du type feuille , possède un identifiant correspondant à l'identifiant d'un script déclaré dans le fichier data.xml, le générateur d'interfaces sait qu'il doit exploiter le paramétrage de ce script pour générer une page formulaire lorsque l'utilisateur demande à entrer dans la rubrique concernée. Le processus mis en oeuvre est alors celui de la figure 3. Le fichier service tree.xml La plupart du temps, la première étape de conception d'un service mettant en oeuvre le générateur d'interfaces selon l'invention consiste à établir son arborescence et l'enchaînement fonctionnel entre les rubriques, à l'aide d'un document appelé Storyboard . lo On donne sur la figure 4 un exemple de définition sous forme d'un arbre de rubriques d'un service touristique. A partir de la page d'accueil, l'utilisateur peut accéder à une ou plusieurs rubriques contenant elle-même une ou plusieurs sous-rubriques, comme défini sur la figure 5 pour la rubrique Adresses utiles : Le rôle du fichier service_tree.xml est de permettre une description simple en XML de l'arborescence d'un ou plusieurs services, en fournissant: o les identifiants des intitulés des rubriques et sous-rubriques de chaque service, chacune étant vue comme une branche de l'arbre (Visites-> Sites & Monuments) o les identifiants des scripts décrits dans le fichier data.xml permettant la recherche d'un type d'information particulier (restaurants, hôtels, magasins, ...). Chaque script est alors vu comme une feuille ou noeud terminal de l'arborescence d'un service. A partir de cette description XML, le générateur d'interfaces est capable de construire automatiquement l'enchaînement des pages listant les rubriques et sous-rubriques disponibles dans le service, jusqu'à l'aboutissement à un formulaire de recherche d'un type d'information précis (Restaurants, Distributeurs de billets, ...). Le fichier service tree.xml n'a en revanche aucune connaissance du paramétrage du formulaire et de la méthode d'accès aux sources de données lesquels sont décrist dans les scripts du fichier data.xml. C'est ce découplage entre la description de l'agencement en rubriques et la méthode d'accès final aux données qui distingue l'invention dessystèmes actuels car ainsi: - il est possible de changer de fournisseur de contenus sans pour s autant toucher à l'organisation des rubriques du service, - ou encore il est possible de changer l'intitulé d'une rubrique ou sa place dans le service sans pour autant toucher aux méthodes d'accès aux données. Le format du fichier service tree.xml est décrit par la DTD (Document 10 Type Definition) suivante: Un exemple de contenu pour le fichier service_tree.xml est donné ci-20 dessous: id="bestsitemuseum"/> i d= "site "/> Id="museum"/> id="circuit"/> id="tourism"/> id="excursionnist"/> id="webcam"/> id="prescity"/> 30 35 40 45 id="day"> id="daymeeting"/> id="dayshow"/> id="daysport"/> id="daychristmas"/> id="dayexhibition"/> id="horsemanship"/> id="golf"/> id="karting"/> id="walk"/> id="navigate"/> id="animalpark"/> id="a ttractionpark"/> id= "icerink "/> id="cycling"/> id="piscine"/> id="roller"/> Id="fly"/> Comme on peut le voir, il s'agit uniquement d'une structure arborescente simple, chaque noeud de l'arbre étant identifié avec un identifiant id. Cet identifiant id n'est pas nécessairement unique puisqu'une même rubrique peut apparaître à plusieurs endroits dans l'arborescence d'un service. Les balises permettent de marquer les débuts et fin de 30 définition d'un service. On a donc une balise par service. Chaque service est identifié par un identifiant unique. Les balises permettent de marquer les début et fin de définition de l'arborescence de navigation dans un service. Ces balises contiennent une ou plusieurs balises filles qui se lient les unes aux autres de manière arborescente. Chaque balise possède un attribut id (pas nécessairement unique) qui sera utilisé par le générateur d'interfaces pour rendre une ou deux fonctions suivant la position de la balise dans l'arborescence des menus. Construction des rubriques du service Chaque balise correspond à une rubrique du service (ou une sous-rubrique suivant qu'il s'agit de la page d'accueil ou pas). Lorsque une balise possède des balises filles, le générateur d'interfaces sait que cette rubrique propose à l'utilisateur une ou plusieurs sous-rubriques. Dans ce cas, le générateur d'interfaces utilise la valeur des attributs 5 id de chaque balise fille pour générer la liste des intitulés à afficher dans la page pour cette rubrique. Ce processus est mis en oeuvre pour tous les noeuds non terminaux de l'arborescence appelés branches de l'arbre et représentées soulignées dans l'exemple précédent. lo Ainsi, le noeud dont l'identifiant id est day' correspond à la rubrique dont l'intitulé est En journée et le noeud dont l'identifiant id est 'visites' correspond à la rubrique dont l'intitulé est Visites qui est une sous-rubrique de la rubrique En journée . Au final, après un clic sur la rubrique En journée le générateur d'interfaces génèrera une page contenant quatre liens pointant vers quatre sous-rubriques (correspondants aux quatre balises filles de la balise dont l'identifiant id est 'day'). Cette page est montrée sur la figure 6. Pour obtenir l'intitulé correspondant à une rubrique (resp. une sousrubrique), le générateur d'interface exploite le contenu du fichier dictionnaire contenant les ressources linguistiques pour une langue donnée. Le fichier data.xml Le fichier data.xml contient l'ensemble du paramétrage des scripts d'accès aux sources de données. Il décrit pour chaque script quels critères de recherche doivent être proposés à l'utilisateur, quels sont les programmes et paramètres d'accès aux fournisseurs de contenus, et enfin comment présenter les données résultat à l'utilisateur. Chaque script d'accès aux données est paramétrable suivant une DTD (Document Type Definition) bien précise, avec les paramètres suivants: 30 - l'identifiant unique du script proprement dit, - le nom du programme (classe Java, script CGI, ...) permettant l'accès à la source de données utilisée dans ce script (que ce soit une base de données, une API distante renvoyant un flux XML, ...), - optionnellement, un ou plusieurs paramètres à destination du programme d'accès permettant de préciser le type de données à récupérer dans la source de données utilisée (typiquement, pour une base de données relationnelle, il s'agit de la table à parcourir), la liste des critères de recherche proposés à l'utilisateur pour ce type de données (localisation, prix, horaires, note d'évaluation, ...). Chaque critère est représenté par un identifiant unique, que le programme d'accès sait gérer. Un même critère peut être utilisé pour plusieurs types de données: par exemple, le critère de prix peut servir à trouver aussi bien un hôtel qu'un io restaurant dans une base de données. Lorsque le script est utilisé par la suite, le générateur d'interfaces possède tous les éléments pour construire automatiquement une page formulaire du type de celle de la figure 7. Lorsque l'utilisateur valide le formulaire après avoir renseigné un ou 15 plusieurs critères, le script sait comment interroger la source de données pour lui fournir une liste de réponses. - la liste des descripteurs des données à afficher dans la liste de réponses obtenues pour la recherche. Par exemple, pour un guide touristique, la plupart du temps, on choisira d'afficher dans la liste de résultats la localisation (ville, quartier) du POI ou de l'événement trouvé. On donne sur la figure 8 un exemple de rendu graphique d'une liste de réponses, avec affichage pour chaque hôtel d'un bref compte rendu sur la localisation, le prix et le nombre d'étoiles. - la liste des descripteurs des données à afficher dans chaque fiche détaillée de la réponse obtenue pour la recherche. Par exemple, pour un guide touristique, pour certains Points d'Intérêts (restaurant, hôtel,..), on pourra décider d'afficher une photo de façade du lieu. On trouvera ci-dessous la DTD pour ce type de fichier de configuration data.xml: 15 20 25 --> --> Suivent ci-dessous des exemples de contenu pour le fichier data.xml décrivant quatre scripts d'accès à des données: le script fashion décrit la procédure d'accès à des Points d'intérêts (POI) de type magasins dans le domaine de la mode fournis par un fournisseur de contenus A. Le programme Java permettant l'accès à ces POI est dao.providerA.PoiDAO. Ce programme Java reçoit en paramètre une valeur permettant de savoir quel type de POI récupérer (typePOl=shop). dao.providerA.PoiDAO shop women_fashion men_fashion child fashion 45 50 dress_fashion bigshop_fashion le script resto décrit la procédure d'accès à des Points d'intérêts (POI) de type restaurants fournis par une base de données touristique d'un fournisseur B. Le programme Java permettant l'accès à ces POI est dao.providerB.PoiDAO. Ce programme Java reçoit en paramètre une valeur permettant de savoir quel type de POI récupérer (typePOl=restaurant). dao.providerB.PoiDAO restaurant chineseljapaneselthailvietnamese brasserie-germanIbelgian creperieI frenchIcheese_and_wine spannishjitalianIpizzeria seafoodifish_food local_food mexican le script hotel décrit la procédure d'accès à des Points d'intérêts (POI) de type hôtels fournis par une base de données touristique d'un fournisseur B. Le programme Java permettant l'accès à ces POI est dao.providerB.PoiDAO. Ce programme Java reçoit en paramètre une valeur permettant de savoir quels types de POIs récupérer (typePOl=hotel ou hotel-restaurant). dao.providerB.PoiDAO hotellhotel-restaurant le script dayexhibition décrit la procédure d'accès à des Evènements (Event) de type expositions fournis par un fournisseur de contenus C. Le programme Java permettant l'accès à ces événements est dao.providerC.EventDAO. Ce programme Java reçoit en paramètres 2 valeurs, l'une permettant de savoir quel type d'événement récupérer, l'autre permettant de savoir s'il s'agit des événements de la journée ou de la nuit. dao.providerC.EventDAO exhibition day Pour chaque script, la balise contient toutes les informations de paramétrage de l'accès à la source de données. La balise indique le programme responsable de l'interrogation de cette source de données. Il faut noter que si l'exemple donné ici d'accès aux données concerne une classe Java, il serait tout à fait possible de paramétrer également un programme écrit en C++ ou une URL distante. La balise contient une série de paramètres sous la forme nom, valeur . Ces paramètres pré-définis sont utilisés par le programme (Java ou autre) pour accéder à la bonne information. Il s'agira par exemple du de la table à interroger dans une base de données contenant plusieurs tables. i0 Pour chaque script, la balise contient toutes les informations de paramétrage des critères de recherche à proposer dans un formulaire. Chaque critère est identifié par une balise ayant un nom unique. Par exemple, le critère de prix sera identifié par la balise tandis que le critère de localisation sera identifié par une balise . Il suffit d'ajouter une de ces balises dans la balise pour que le générateur d'interfaces active automatiquement le critère correspondant dans la page formulaire de recherche. Inversement, si la balise correspondant à un critère n'apparaît pas dans la balise , le générateur d'interfaces considère qu'il ne doit pas le proposer à l'utilisateur. La liste de critères pouvant être définis n'est pas limitée. Pour qu'un nouveau critère soit pris en compte, il suffit de le déclarer dans la DTD du fichier data.xml et d'implémenter son traitement dans le générateur d'interfaces et les programmes d'accès aux sources de données. Pour un service de vente de voitures par exemple, il est tout à fait possible d'imaginer d'ajouter un critère de couleur symbolisé dans la balise par une balise fille . Certains critères sont eux même paramétrés par des sous-critères identifiés eux aussi par des balises filles ayant un nom unique. Ainsi, le critère 30 de localisation peut contenir plusieurs sous-critères: pour proposer une recherche de type le plus proche - pour proposer une recherche par quartier pour proposer une recherche Ville intra-muros ou Environs Pour chaque script, la balise contient le paramétrage des types de données à afficher dans la liste de réponses obtenues après envoi de la requête multicritères et obtention d'au moins une réponse de la source de données. Chaque type d'information est identifié par une balise ayant un nom unique. Par exemple, l'information de prix sera identifiée par la balise io tandis que l'information de quartier sera identifiée par une balise . Il suffit d'ajouter une de ces balises dans la balise pour que le générateur d'interfaces affiche automatiquement le type d'information correspondant dans la page résultat de la recherche. Inversement, si la balise correspondant à un type d'information n'apparaît pas dans la balise , le générateur d'interfaces considère qu'il ne doit pas l'afficher à l'utilisateur dans la liste de réponses. La liste des types d'informations pouvant être affichés n'est pas limitée. Pour qu'un nouveau type d'information soit pris en compte, il suffit de le déclarer dans la DTD du fichier data.xml et d'implémenter son traitement dans le générateur d'interfaces notamment dans la partie générant la page de résultats. Pour un service de vente de voitures par exemple, on pourrait très bien imaginer d'ajouter l'information de couleur symbolisée dans la balise par une balise fille . Pour chaque script, la balise contient le paramétrage des types d'informations à afficher dans la fiche détaillée d'un élément de la liste de réponses obtenues après envoi de la requête multicritères et obtention d'au moins une réponse de la source de données. Chaque type d'information est identifié par une balise ayant un nom unique. Par exemple, l'information de prix sera identifiée par la balise tandis que l'information de qualité (nombre d'étoiles d'un restaurant par exemple) sera identifiée par une balise . Il suffit d'ajouter une de ces balises dans la balise pour que le générateur d'interfaces affiche automatiquement le type d'information correspondant dans la fiche détaillée de chaque élément de la réponse. Inversement, si la balise correspondant à un type d'information n'apparaît pas s dans la balise , le générateur d'interfaces considère qu'il ne doit pas l'afficher à l'utilisateur dans la fiche détaillée. La liste des types d'informations pouvant être affichés n'est pas limitée. Pour qu'un nouveau type d'information soit pris en compte, il suffit de le déclarer dans la DTD du fichier data.xml et d'implémenter son traitement io dans le générateur d'interfaces notamment dans la partie générant les fiches détaillées de chaque élément de la réponse. Pour un service de vente de voitures par exemple, on pourrait très bien imaginer d'ajouter l'information de couleur symbolisée dans la balise par une balise fille . Lien entre le fichier service tree.xml et les scripts du fichier data.xml Lorsque une balise ne possède pas de balise fille, le générateur d'interfaces sait que cette rubrique (resp. sous-rubrique) doit être liée à un script déclaré dans le fichier data.xml permettant l'accès aux données cherchées via un formulaire de saisie de critères de recherche. Ce processus est mis en oeuvre pour certains noeuds terminaux de l'arborescence, appelés feuilles de l'arbre et représentées en italique dans l'exemple de fichier service_tree.xml ci-dessus, car ils mettent fin au système de navigation dans les rubriques/sous-rubriques en proposant à l'utilisateur un formulaire de recherche qui va lui permettre d'accéder finalement à l'information qu'il recherche. Le générateur d'interfaces utilise la valeur de l'attribut id de la balise _pour retrouver le script ayant cet id dans la liste de scripts déclarés dans le fichier data.xml, chaque script étant identifié par un id unique. Ainsi, on voit dans l'exemple ci-dessus que la sous-rubrique dont l'id est 'visites' propose l'accès à un certain nombre de scripts tels que Sites et musées à ne pas manquer dont l'id est 'bestsitemuseum'. Finalement, après un clic sur la rubrique Visites , le générateur d'interface générera une page du type de celle de la figure 9. Et après un clic sur la sous-rubrique Sites/Monuments , dont l'identifiant est sites', le générateur d'interfaces proposera un formulaire de recherche correspondant aux critères activés dans le script ayant le même identifiant sites', ce qui donne un résultat du type de celui de la figure 10. Pour générer automatiquement la page formulaire d'un script, le générateur d'interfaces recherche un certain nombre de ressources linguistiques dans le fichier dictionnaire de la langue courante, en prenant en io compte la liste de critères activés dans la configuration du script. On se reportera donc: au paragraphe sur le fichier data.xml pour savoir comment sont paramétrés les scripts pour activer/désactiver un ou plusieurs critères de recherche, au paragraphe suivant sur les fichiers dictionnaires messages_ .xml pour savoir quel processus est mis en oeuvre pour établir l'intitulé et la liste des valeurs proposées pour chaque critère Au vu de ce qui vient d'être dit, on voit donc que le fichier service tree.xml joue un rôle central dans le mécanisme de génération automatique du service puisque c'est l'identifiant contenu dans chaque balise qui permet de faire le lien entre les trois fichiers de configuration data.xml, service_tree.xml et messages_ . xml. Il convient de remarquer que dans les balises un même identifiant id peut apparaître à plusieurs endroits dans l'arborescence du fichier service tree.xml puisqu'une sous-rubrique Shopping peut être proposée à deux endroits dans le service, dans une rubrique Courses ou bien une rubrique Loisirs par exemple. Les fichiers messaqes .xml Les fichiers dictionnaires messages_ .xml contiennent chacun la liste des ressources linguistiques pour une langue donnée. Il existe un fichier par langue, la langue étant identifiée dans le nom du fichier par deux lettres. Ainsi, le fichier messages_fr.xml contient les ressources linguistiques en français tandis que le fichier messages_en.xml contient ces mêmes ressources linguistiques traduites en anglais. Les fichiers dictionnaires sont utilisés à 2 niveaux dans la construction du service: - ils permettent d'obtenir l'intitulé de chaque rubrique ou sous-rubrique du service à partir de l'identifiant. Si l'identifiant de la rubrique A ne pas manquer dans le fichier service_tree.xml est selectedevent' par exemple, io le générateur d'interfaces cherchera l'intitulé version anglaise de cette rubrique dans le fichier messages_en.xml en lisant la valeur de la ressource linguistique dont l'identifiant est 'selectedevent. title'. Ce mécanisme permet d'avoir une traduction automatique dans N langues des rubriques du service et une séparation claire entre l'arborescence des rubriques et leur intitulé final. - ils permettent d'obtenir la liste des intitulés des valeurs possibles des critères à proposer dans le formulaire de recherche pour un script d'accès aux données ainsi que l'intitulé du titre à mettre devant chaque critère. Par exemple, si l'identifiant du script dans le fichier data.xml est 'hotel' et que, pour ce script, le critère de prix dont l'identifiant est price' est actif, la liste des valeurs proposées dans le formulaire concernant ce critère de prix sera établie sous cette forme dans le fichier dictionnaire français: Indifférent moins de 30 de 30 à 60 de 60 à 90 de 90 à 120 plus de 120 Et l'intitulé du critère de prix dans le formulaire sera contenu dans la ressource: Budget II suffit alors d'appeler le script 'hotel' en ajoutant une balise dans le fichier service_tree.xml pour obtenir un formulaire de ce style lorsque l'utilisateur clique sur la rubrique Hôtels (Figure 11). Le critère de prix a bien pour intitulé Budget dans le formulaire et propose la liste de valeurs possibles apparaissant sur la figure 12. Lorsque pour un critère donné, aucune valeur du type 'field.criteria. hotel.XXX' n'est trouvée dans le dictionnaire, le générateur io d'interfaces sait qu'il s'agit d'un critère à saisie libre, dont le nombre de valeurs possibles n'est pas pré-déterminé. C'est le cas par exemple pour le critère de recherche par Nom , identifié par une balise : il n'y a aucune ressource linguistique dont l'identifiant commence par 'field.name.hotel', et par conséquent dans le formulaire de saisie on trouve un champ de saisie textuelle libre plutôt qu'un menu déroulant. REVENDICATIONS 1. Générateur d'interfaces pour systèmes d'accès à des données, destiné à fournir une première interface d'accès par navigation dans une arborescence et une deuxième interface d'accès par saisie, ladite arborescence présentant au moins un noeud terminal de liaison à ladite deuxième interface, caractérisé en ce que ledit générateur d'interfaces comprend, au moins: - un module de traitement de la navigation, apte à fournir ladite première io interface, - un module de traitement de scripts de saisie, apte à fournir la deuxième interface, chaque script étant défini, au moins, par les champs de configuration suivants: * un identifiant unique, * un identifiant d'un programme d'accès à une source de données, * une liste de critères de saisie, ledit noeud terminal de liaison de l'arborescence de navigation étant rattaché à un script de la deuxième interface par ledit identifiant unique de script. 2. Générateur d'interfaces selon la revendication 1, caractérisé en ce que ledit module de traitement de scripts est apte à générer un formulaire de saisie associé à ladite liste de critères de saisie. 3. Générateur d'interfaces selon l'une des revendications 1 ou 2, caractérisé en ce que chaque script est également défini par les champs de configuration optionnels suivants, pris séparément ou en combinaison: * un identifiant de la source de données, * le nom de ladite source, * au moins un paramètre d'identification du type de données à accéder dans ladite source, * une liste de types de données à fournir en réponse auxdits critères de 30 saisie, * une liste de types de données à fournir sous forme détaillée en réponse auxdits critères de saisie. 4. Générateur d'interfaces selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend en outre un module de traduction, apte à fournir un intitulé dans une langue donnée pour: - chaque rubrique associée à chaque noeud de l'arborescence de navigation, 5 - chaque critère de saisie de chaque script, - des valeurs présélectionnées de critères de saisie de chaque script. 5. Générateur d'interfaces selon la revendication 4, caractérisé en ce que le module de traduction comprend une base d'intitulés associée à chaque langue, chaque intitulé étant identifié par un identifiant unique commun à toutes les bases des intitulés. 6. Générateur d'interfaces selon la revendication 5, caractérisé en ce que ledit identifiant unique commun est associé à chaque noeud de l'arborescence de navigation. 7. Générateur d'interfaces selon la revendication 5, caractérisé en ce que ledit 15 identifiant unique commun est associé à chaque script de saisie et à chaque critère de saisie de chaque script.