FR2809844A1 - Systeme de publication multi-terminal et procede de mise en oeuvre correspondant - Google Patents

Systeme de publication multi-terminal et procede de mise en oeuvre correspondant Download PDF

Info

Publication number
FR2809844A1
FR2809844A1 FR0007073A FR0007073A FR2809844A1 FR 2809844 A1 FR2809844 A1 FR 2809844A1 FR 0007073 A FR0007073 A FR 0007073A FR 0007073 A FR0007073 A FR 0007073A FR 2809844 A1 FR2809844 A1 FR 2809844A1
Authority
FR
France
Prior art keywords
type
webbike
instruction
making
language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0007073A
Other languages
English (en)
Other versions
FR2809844B1 (fr
Inventor
Francois Ziserman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WOKUP SA
Original Assignee
WOKUP SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by WOKUP SA filed Critical WOKUP SA
Priority to FR0007073A priority Critical patent/FR2809844B1/fr
Priority to AU2001262431A priority patent/AU2001262431A1/en
Priority to EP01936548A priority patent/EP1285361A1/fr
Priority to PCT/FR2001/001500 priority patent/WO2001093094A1/fr
Priority to US10/297,221 priority patent/US20030158894A1/en
Publication of FR2809844A1 publication Critical patent/FR2809844A1/fr
Application granted granted Critical
Publication of FR2809844B1 publication Critical patent/FR2809844B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/986—Document structures and storage, e.g. HTML extensions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application

Abstract

L'invention concerne un système de publication multi - terminal, du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux, selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations. Selon l'invention, un tel système comprend :- au moins un module (30, 301, 302, 303) de création d'objets à partir de données brutes;- un module (31) de génération de réponse sous un format de présentation générique, en réponse à une requête (51) formulée par un terminal et relative à une application donnée;- un module (32) de présentation, permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.

Description

<Desc/Clms Page number 1>
Système de publication multi - terminal et procédé de mise en #uvre correspondant.
Le domaine de l'invention est celui des réseaux de communication, auxquels accèdent des terminaux de types différents.
Plus précisément, l'invention concerne un système de publication multi - terminal, permettant de publier un même document sous différents formats, de façon à le rendre consultable à partir de différents types de terminaux de communication.
L'invention s'applique notamment, mais non exclusivement, à la publication d'informations disponibles sur le réseau mondial Internet, ou sur tout autre réseau de type internet, vers des terminaux de types variés, tels que des terminaux de type WAP (en anglais "Wireless Application Protocol"), des terminaux de type PDA (en anglais "Personal Digital Assistant"), des terminaux de type Minitel, etc.
L'invention s'applique également, par exemple, à la publication d'informations contenues dans des bases de données, des fichiers, ou des modules de type java.
La publication de mêmes informations vers des terminaux de types différents est rendue difficile par la diversité des langages informatiques et des protocoles de communication, mis en #uvre dans chaque type de terminal. Ainsi, par exemple, les téléphones mobiles de type WAP (en anglais "Wireless Application Protocol") utilisent le langage WML (en anglais "Wireless Markup Language"), alors que des terminaux tels que les ordinateurs personnels mettent en #uvre un langage du type HTML (en anglais "Hypertext Markup Language").
À ce jour, plusieurs solutions ont été proposées au problème de la publication d'informations vers des terminaux de types différents.
Une première solution, permettant de rendre un service accessible à différents types de terminaux, consiste à développer autant de versions de ce service qu'il existe de types de terminaux pouvant y accéder. La mise en #uvre
<Desc/Clms Page number 2>
d'une telle solution garantit une présentation du service de qualité, adaptée au type de terminal utilisé.
Un inconvénient de cette technique de l'art antérieur est qu'elle nécessite un temps de développement important.
Un autre inconvénient de cette technique de l'art antérieur est que les travaux de maintenance sont rendus difficiles par le nombre élevé de versions du service, qui s'accroît avec le nombre de types de terminaux cibles.
Dans le cas, par exemple, où un utilisateur souhaite accéder à un site Web à l'aide d'un téléphone mobile, il est nécessaire, selon cette première solution, de mettre en #uvre une passerelle de type WAP (en anglais "Wireless Application Protocol") entre le réseau de type internet et le réseau mobile, et de développer une nouvelle version du site Web, construit à partir d'un langage du type HTML (en anglais "Hypertext Markup Language"), qui soit adaptée au mobile, c'est-àdire construite notamment à partir d'un langage du type WML (en anglais "Wireless Markup Language").
Une autre solution consiste à réaliser une conversion automatique du contenu des services. On utilise, dans ce dessein, un ensemble de règles génériques qui permettent, par exemple, de transformer les pages HTML des sites Web en d'autres formats, tels que le format WML, ou le format "HTML light". De telles règles génériques peuvent par exemple consister à dégrader la qualité des images, à transformer les tags HTML, etc.
La mise en #uvre d'une telle solution, proposée, par exemple, par HelpInHand ASA BabelServer (marque déposée), consiste à réaliser une republication de langage à langage, à l'aide d'un traducteur adapté. Selon cette technique, les adresses des localisateurs de ressources uniformes (URL, en anglais "Uniform Resource Locator") sont simplement filtrées par le traducteur.
Un inconvénient de cette technique de l'art antérieur est que les outils de conversion mis en #uvre n'ont pas la connaissance du service traité, et le résultat obtenu est donc de mauvaise qualité. Notamment, ces outils ne sont pas capables d'identifier les informations pertinentes au sein du service à convertir.
<Desc/Clms Page number 3>
Un autre inconvénient de cette technique de l'art antérieur est qu'elle est uniquement adaptée au langage WML, et donc à la conversion automatique d'un site Web, de manière à le rendre accessible aux téléphones mobiles.
Une telle technique a encore pour inconvénient de ne pas permettre de filtrer les informations contenues dans le site Web, en fonction du terminal destinataire.
Encore un autre inconvénient de cette technique de l'art antérieur est qu'elle ne permet pas de mettre en ligne un système de paiement adapté, permettant notamment aux utilisateurs de terminaux de type WAP ou PAD par exemple, d'accéder aux services payants du réseau Internet.
D'autres solutions, dites de republication par transformation prédéfinie, ont été proposées, notamment dans les serveurs "Portal To Go" d'Oracle et "WebSphere Transcoding Publisher" d'IBM (marques déposées).
Ainsi, le module "WebSphere Transcoding Publisher" met en #uvre un moteur de transformation permettant, à l'aide d'un ensemble de règles génériques et spécifiques, une transformation directe des données brutes extraites de sources d'informations aux formats HTML ou XML, en données au format XML, accessibles par une pluralité de terminaux de types différents. Un tel module agit comme un proxy.
Un inconvénient de cette technique de l'art antérieur est que le processeur mis en #uvre au sein d'un tel module ne possède aucune intelligence et n'est donc pas capable d'identifier les informations pertinentes au sein des données brutes à transformer.
Un autre inconvénient de cette technique de l'art antérieur est que la présentation des données transformées est directement liée à la présentation des données brutes avant transformation, quel que soit le type de terminal utilisé.
Notamment, dans le cas où un utilisateur souhaite accéder à un site Web à l'aide d'un téléphone mobile, la mise en #uvre du module "WebSphere Transcoding Publisher" contraint l'utilisateur à adopter une navigation, au sein du site transformé, identique à celle du site Web d'origine.
<Desc/Clms Page number 4>
La solution "Portal - To Go" d'Oracle consiste en un extracteur de données, composé d'une pluralité de modules d'extraction, et en un moteur de transformation. Chaque module d'extraction est une API (en anglais "Application Program Interface", interface de programme d'application) qui permet respectivement d'extraire des données brutes au format HTML, XML, ou issues de bases de données par exemple, et de les convertir au format XML. Dans ce dessein, un extracteur effectue une recherche d'expressions régulières, à partir d'un librairie enregistrée, c'est-à-dire qu'il met en #uvre une recherche de motifs (en anglais "patterns"), par exemple au sein d'une page Web donnée, en fonction d'une grammaire prédéterminée.
Les données converties sont ensuite transformées, de façon à être accessibles à différents types de terminaux - destination. Le moteur de transformation "Portal - To - Go" comprend autant de modules de transformation que de types de terminaux - destination : chacun de ces modules permet d'adapter la présentation des données converties au format XML au type de terminal - destination.
Un inconvénient de cette technique de l'art antérieur est qu'elle est complexe à mettre en #uvre.
Un autre inconvénient de cette technique de l'art antérieur est qu'elle nécessite un temps de développement élevé, en raison du grand nombre de langages (en nombre égal au nombre de types de terminaux - destination) qu'il est nécessaire de mettre en #uvre dans le moteur de transformation.
Cette technique "Portal - To - Go" a encore pour inconvénient de proposer au terminal - destination une présentation des données transformées, qui est dépendante de la présentation des données brutes d'origine.
Encore un autre inconvénient de cette technique de l'art antérieur est que l'extracteur mis en #uvre ne permet pas un suivi automatique d'éventuels liens entre différentes pages Web. Notamment, si, au sein d'une page Web, un tel extracteur identifie une adresse URL (en anglais "Uniform Resource Locator")
<Desc/Clms Page number 5>
renvoyant vers une autre page Web, il ne demande pas à y accéder pour en extraire les données qu'elle contient.
La technique "Portal-To-Go" a encore pour inconvénient de ne pas permettre de respecter l'arborescence de la page Web de laquelle sont extraites les informations constitutives des objets. En effet, la recherche d'expressions régulières mise en #uvre ne tient pas compte de la structure arborescente de la page analysée. On peut alors extraire de la page un motif appartenant, en partie, à une première branche, et, en partie, à une deuxième branche de la structure arborescente de la page. Ainsi, après extraction des données brutes contenues dans une page Web, on perd toute notion de navigation au sein des objets contenus dans la page analysée.
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir un système de publication multi - terminal, permettant de publier un même document sous différents formats, de façon à le rendre consultable à partir de différents types de terminaux de communication.
Un autre objectif de l'invention est de mettre en #uvre un système de publication multi - terminal qui soit peu coûteux, et peu complexe à mettre en #uvre.
L'invention a également pour objectif de mettre en #uvre un système de publication multi-terminal, qui s'adapte à tout type de source de données ainsi qu'à tout type de terminal de consultation.
L'invention a encore pour objectif de fournir un système de publication multi - terminal évolutif, permettant de s'adapter facilement à l'évolution des sources d'informations et de documents.
L'invention a également pour objectif de mettre en #uvre un système de publication multi - terminal, dans lequel les concepts de données et de présentation des données sont indépendants.
<Desc/Clms Page number 6>
Un autre objectif de l'invention est de mettre en #uvre un système de publication multi - terminal permettant de filtrer les informations des sources de données en fonction du terminal, ou du type de terminal, auquel elles sont destinées.
L'invention a encore pour objectif de fournir un système de publication multi - terminal présentant une indépendance totale de la source d'informations et du terminal - destination, c'est - à - dire dans lequel les traitements mis en #uvre ne dépendent ni de la nature des informations extraites des sources de données, ni du type de terminal auquel elles sont destinées.
Encore un autre objectif de l'invention est de mettre en #uvre un système de publication multi - terminal, dans lequel le contenu et la présentation des informations proposées au terminal - destination sont parfaitement adaptés au type de terminal - destination.
L'invention a encore pour objectif de fournir un système de publication multi - terminal adapté à tous les terminaux légers.
Ces objectifs, ainsi que d'autres qui apparaîtront par la suite sont atteints selon l'invention, à l'aide d'un système de publication multi - terminal, du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux, selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations.
Selon l'invention, un tel système comprend : au moins un module de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites de ladite au moins une source d'informations et/ou générées par ledit au moins un module de création d'objets ; un module de génération de réponse sous un format de présentation générique, en réponse à une requête formulée par un terminal et relative à une application donnée, ladite application étant définie, au sein dudit module de génération de réponse, par une pluralité de contextes et une politique de navigation parmi lesdits contextes, chaque contexte
<Desc/Clms Page number 7>
comprenant au moins une action et/ou au moins un objet, créé par ledit au moins un module de création d'objets, ladite réponse résultant d'une navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; un module de présentation, permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la publication multi - terminal, permettant de rendre un document accessible à une pluralité de terminaux de types différents. En effet, elle repose notamment sur le concept nouveau de séparation de l'information et de la présentation de l'information. L'invention repose également sur un nouveau concept de navigation au sein d'un ensemble de contextes, dans lesquels sont regroupés des actions et/ou des objets créés par le système de publication multi - terminal. Une réponse d'un tel système selon l'invention à la requête d'un terminal de communication est ainsi élaborée par une technique générique de navigation, indépendante du type de terminal de consultation, qui permet de construire une structure arborescente d'objets, créés en tout ou en partie à partir des données contenues dans des sites Web, des bases de données, des fichiers, ou des modules java par exemple.
Avantageusement, ladite réponse sous un format de présentation générique est un arbre de type XML ou de type SGML.
En effet, le langage XML (en anglais "Extended Markup Language"), qui est un langage extrait du langage SGML (en anglais "Standard Generalized Markup Language"), est un langage générique particulièrement adapté à la publication et à l'échange de données.
Selon une caractéristique avantageuse de l'invention, un tel système comprend en outre un module d'interfaçage permettant d'intercepter et d'analyser ladite requête formulée par un terminal, de manière à : identifier le type dudit terminal ;
<Desc/Clms Page number 8>
créer une nouvelle requête, sous un format de requête générique, destinée audit module de génération de réponse.
Ainsi, le type de terminal de consultation étant identifié, le système selon l'invention peut renvoyer une réponse, dont le contenu et la présentation sont parfaitement adaptés au terminal ayant émis la requête.
Selon une technique avantageuse, chaque objet comprend au moins un membre relatif à la structure dudit objet et au moins un constructeur, ledit au moins un constructeur permettant audit au moins un module de création d'objets de renseigner le contenu dudit au moins un membre.
On peut par exemple imaginer qu'un objet "film" soit constitué de trois membres, à savoir un premier membre "titre du film", un second membre "résumé du film", et un troisième membre "metteur en scène".
Dans un mode de réalisation avantageux de l'invention, ledit au moins un module de création d'objets appartient au groupe comprenant: un module de création d'objets, appelé module Webbike, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une source de données contenant au moins un document exprimé selon un langage de type "markup" ; un module de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une base de données du type SQL ; (en anglais "Structured Query
Language", langage d'interrogation structuré) un module de création d'objets, construit à partir d'un langage du type java, permettant de fournir au moins une fonction de création d'objets à partir de données brutes générées par ledit module de création d'objets et/ou extraites d'au moins une source d'informations prédéterminées.
Un tel système selon l'invention permet ainsi de publier sur un terminal ayant émis une requête, des données provenant de sources d'informations multiples, et notamment de sites Web, de bases de données, de fichiers du type XML, ainsi que des données générées ou extraites en mettant en #uvre un module
<Desc/Clms Page number 9>
de type java. On peut envisager qu'un objet soit entièrement créé à partir de données extraites d'un site Web. On peut aussi envisager que certains membres d'un objet soient renseignés à partir de données extraites d'une base de données, et que, par exemple, l'ensemble des autres membres de l'objet soient renseignés à partir de données générées par un module de type java.
Les objets créés par les modules de création d'objets sont préférentiellement décrits à l'aide d'un langage du type SIDL (en anglais "Service Interface Définition Language"), mais tout autre type de langage adapté à l'invention peut également être utilisé.
De façon avantageuse, ledit module de présentation est construit à l'aide d'un langage du type XSL (en anglais "Extended Stylesheet Language").
Selon une caractéristique avantageuse de l'invention, au sein dudit module de génération de réponse, ladite au moins une application est composée, selon un premier langage spécifique, d'un conteneur service, décrivant ledit service, et d'au moins un conteneur contexte, correspondant chacun à une étape de ladite navigation.
Afin de faciliter la lecture, un tel premier langage spécifique sera appelé, dans la suite de la description, langage MDSP (en anglais "Multi - Device Server Page"). Chaque application est ainsi composée d'un conteneur service et d'un ou plusieurs conteneurs contexte. Le conteneur service permet de décrire les instructions à effectuer au lancement de l'application. Il permet également de déclarer des entités (par exemple des variables ou des procédures) utilisables dans toute l'application considérée. Le conteneur contexte permet quant à lui de décrire un contexte, c'est-à-dire une étape de la navigation au sein de l'application considérée.
Il existe un unique conteneur service dans chaque application. Cependant, comme exposé dans la suite de la description, l'invention met en #uvre des instructions permettant, au cours d'un session, de changer de service. Pour chaque utilisateur d'un terminal de consultation, l'émission d'une requête et la
<Desc/Clms Page number 10>
visualisation de sa réponse, au cours d'une unique session, peut donc être associée à une pluralité de services.
Avantageusement, un conteneur est composé d'au moins un composant, permettant de regrouper au moins une instruction.
De façon avantageuse, un tel système selon l'invention met en #uvre six types de composants : des composants de type "point d'entrée", permettant de décrire une première pluralité d'opérations que ledit module de génération de réponse doit effectuer au lancement de l'exécution d'un conteneur service ou d'un conteneur contexte ; - des composants de type "attributs", permettant de décrire une pluralité de variables utilisables dans ledit conteneur courant ; - des composants de type "méthode", permettant de regrouper une pluralité desdites au moins une instruction au sein d'une procédure ; - des composants de type "imports", permettant de décrire ledit au moins un objet nécessaire audit module de génération de réponse, pour générer ladite réponse à ladite requête relative à une application donnée ; - des composants de type "traitement", permettant de décrire une seconde pluralité d'opérations que ledit module de génération de réponse doit effectuer en réponse à une action réalisée par un terminal ; - des composants de type "contenu", permettant de décrire lesdites informations fournies à un terminal au sein de ladite réponse et/ou de décrire ladite au moins une action que peut réaliser ledit terminal à une étape de ladite navigation donnée.
On présente, en annexe 1, des exemples de composants des types exposés ci-dessus. Cette annexe, de même que les suivantes, fait bien sûr partie de la présente description à part entière.
Ainsi, un composant de type point d'entrée est caractérisé par son nom, éventuellement des paramètres, et l'ensemble des instructions que le module de génération de réponse doit effectuer au lancement de l'exécution du conteneur
<Desc/Clms Page number 11>
service ou du conteneur contexte auquel appartient un tel composant de type "point d'entrée".
Un composant de type attribut permet quant à lui de décrire des variables utilisables dans tous les composants du conteneur courant. Ainsi, si le composant attribut appartient à un conteneur service, les variables qu'il déclare sont accessibles depuis tous les contextes de l'application considérée.
L'ensemble des instructions d'un composant de type contenu permettent, lorsqu'elles sont exécutées, de générer un arbre XML contenant l'ensemble des informations que le système de publication multi - terminal selon l'invention propose au terminal ayant émis la requête considérée.
Avantageusement, un tel système selon l'invention met en #uvre les quatre types d'instructions suivants : - des instructions de type "contenu", permettant de générer une partie de ladite réponse sous un format de présentation générique ; - des instructions de type "manipulation de variables", permettant de déclarer et/ou de manipuler au moins une variable ; des instructions de type "navigation", permettant de changer de contexte courant et/ou d'application courante ; des instructions de type "utilisation", pouvant être utilisées par des instructions et/ou des composants.
Selon une première caractéristique avantageuse de l'invention, lesdites instructions de type "contenu" appartiennent au groupe comprenant : une instruction "contenu - littéral", permettant de décrire une chaîne de caractères de ladite réponse sous un format générique ; - une instruction "contenu - objet", permettant de décrire un objet ; - une instruction "contenu - liste", permettant de décrire une liste d'objets ; - une instruction "contenu - item", permettant de décrire un élément d'une liste ; une instruction "contenu - membre", permettant de décrire un membre d'un objet ;
<Desc/Clms Page number 12>
une instruction "contenu - sélection", permettant de sélectionner un item dans une liste ; une instruction "contenu - sélection - multiple", permettant de sélectionner au moins un item dans une liste ; une instruction "contenu - entrée", permettant de décrire un item de type "entrée" par lequel ledit terminal ayant formulé ladite requête peut entrer une valeur ; une instruction "contenu - défilement - action", permettant de se déplacer au sein d'une liste ; une instruction "contenu - action", permettant de décrire une action ; une instruction "contenu - action - changement - de - contexte", permettant de décrire une action qui permet audit terminal ayant formulé ladite requête de changer de contexte ; une instruction "contenu - action - contexte - précédent", permettant audit terminal ayant formulé ladite requête de revenir au contexte précédent.
Ainsi, l'instruction "contenu - littéral", qui permet de décrire une chaîne de caractères à insérer dans l'arbre XML constitutif de la réponse, se caractérise par la chaîne de caractères à insérer et le nom du n#ud de l'arbre XML généré.
L'instruction "contenu - objet" permet, quant à elle, de décrire un objet SIDL que le système selon l'invention propose au terminal ayant émis la requête traitée. Un tel objet peut être référencé par son nom dans tous les composants du contexte auquel appartient le composant de type "contenu". Pour que le composant de type "contenu" qui contient cette instruction soit correctement exécuté, le "contenu - objet" doit être initialisé avant l'appel de l'instruction exécutant le composant "contenu".
On présente, en annexe 2, quelques exemples d'instructions de type "contenu".
Selon une deuxième caractéristique avantageuse de l'invention, lesdites instructions de type "manipulation de variables" appartiennent au groupe comprenant :
<Desc/Clms Page number 13>
une instruction "objet", permettant de déclarer une variable de type "objet" ; une instruction "liste", permettant de déclarer une variable de type "liste" ; une instruction "simple", permettant de déclarer une variable de type "simple", distinct dudit type "objet" et dudit type "liste " ; une instruction "créer", permettant de construire un objet ou une liste d'objets ; une instruction "établissement", permettant d'affecter une valeur à une variable ; une instruction "liste - déplacer", permettant de déplacer un pointeur courant d'une liste, en spécifiant un pas de déplacement ; une instruction "liste - déplacer - vers", permettant de déplacer un pointeur courant d'une liste, en spécifiant une nouvelle position dudit pointeur.
En effet, le langage MDSP permet de déclarer et de manipuler des variables, qui peuvent être utilisées pour stocker des informations ou pour transmettre des paramètres.
Ainsi, l'instruction "objet" permet de déclarer une variable de type objet.
Cet objet peut être référencé par son nom dans tous les composants du conteneur courant. Avant d'être référencé, il doit être initialisé à l'aide d'une instruction prédéterminée. L'instruction "objet" se caractérise par le nom de la variable déclarée et par une classe SIDL de l'objet.
L'instruction "simple" permet quant à elle de déclarer une variable de type simple, c'est-à-dire une variable pouvant contenir une chaîne de caractères, un entier ou un flottant. Elle se caractérise par le nom de la variable et par la valeur que prend éventuellement cette variable à l'initialisation.
L'instruction "créer" permet de construire un objet ou une liste d'objets SIDL déclarés dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la variable à construire, le constructeur SIDL à utiliser, et les valeurs affectées aux paramètres du constructeur.
<Desc/Clms Page number 14>
On présente, en annexe 3, quelques exemples d'instructions de type "manipulation de variables".
Selon une troisième caractéristique avantageuse de l'invention, lesdites instructions de type "navigation" appartiennent au groupe comprenant : - une instruction "changer - contexte", permettant d'instancier un nouveau contexte ; - une instruction "changer - service", permettant d'instancier un nouveau service ; - une instruction " contexte - précédent", permettant de revenir au contexte précédent dans le service courant ; - une instruction "service - précédent", permettant de revenir au contexte précédent avec le dernier contexte dudit service.
En effet, à un instant donné, pour un client donné (c'est-à-dire pour un terminal donné ayant émis une requête à destination du système de publication multi - terminal selon l'invention), il existe un unique contexte courant et un unique service courant. Le langage MDSP permet de changer ce contexte courant et ce service courant par l'entremise d'instructions de type "navigation".
Ainsi, une instruction "contexte-précédent" permet de revenir à un contexte précédent dans le service courant. Le contexte courant devient alors ce contexte, dans l'état où on l'a quitté la dernière fois. La présentation retournée au terminal ayant émis la requête correspond donc à celle décrite par le dernier composant de type "contenu" exécuté sur ce contexte.
On présente, en annexe 4, quelques exemples d'instructions de type "navigation".
Selon une quatrième caractéristique avantageuse de l'invention, lesdites instructions de type "utilisation" appartiennent au groupe comprenant : une instruction "appel", permettant d'appeler un composant "méthode" dans le contexte ou le service courant ; une instruction "si", permettant d'établir une condition sur un ensemble d'instructions ;
<Desc/Clms Page number 15>
une instruction "sinon", faisant suite à une instruction "si" et permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon - si", faisant suite à une instruction "si" et permettant d'établir au moins une autre condition sur ledit ensemble d'instructions ; une instruction "exécuter - contenu", permettant de générer une présentation desdites informations décrites dans un composant "contenu" ; une instruction "SIDL - import", permettant de spécifier un objet à utiliser dans le service courant ; une instruction "paramètre - liste", permettant de regrouper des déclarations de paramètres ; une instruction "paramètre", permettant de spécifier la valeur d'un paramètre ; une instruction "faire", permettant de regrouper dans un composant du type "traitement" des actions à effectuer au lancement de l'exécution d'un contexte ; une instruction "sur", permettant de regrouper des conditions devant être validées pour qu'un composant du type "traitement" s'exécute.
En effet, il existe également, au sein du langage MDSP, des instructions diverses qui peuvent être utilisées par des instructions ou des composants.
Ainsi, une instruction "appel" permet d'appeler une méthode (c'est - à - dire un composant du type "méthode") déclarée dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la méthode appelée et par les valeurs affectées aux paramètres de la méthode.
Une instruction "exécuter - contenu" permet de déclencher la génération de la présentation des informations décrites par un composant contenu. Elle se caractérise par le nom du contenu dont on veut générer la présentation et le nom du modèle XSL que l'on veut utiliser, si l'on ne veut pas utiliser celui du contenu.
On présente, en annexe 5, quelques exemples d'instructions de type "utilisation".
<Desc/Clms Page number 16>
Avantageusement, à la réception par ledit au moins un module de création d'objets d'une demande d'au moins un objet, ladite demande venant dudit module de génération de réponse, ladite au moins une fonction de création d'objets met en #uvre au moins une sous-fonction d'extraction, permettant de renseigner le contenu d'au moins un membre relatif à la structure dudit au moins un objet.
De façon avantageuse, ladite au moins une fonction de création d'objets comprend en outre une sous-fonction de comparaison dudit au moins un objet sur lequel porte ladite demande avec une liste d'objets préalablement au moins partiellement créés, de façon à ne mettre en #uvre ladite au moins une sousfonction d'extraction que pour la création d'objets non préalablement créés et/ou pour compléter des objets préalablement partiellement créés.
Ainsi, si un objet a déjà été créé en réponse à une requête, traitée précédemment par le système de publication multi - terminal selon l'invention, cet objet est réutilisé dans l'élaboration de la réponse à la requête en cours de traitement, et est directement envoyé au module de génération de réponse.
Avantageusement, au sein dudit module Webbike, chaque sous-fonction d'extraction est composée, selon un second langage spécifique, d'au moins une page Webbike comprenant au moins un n#ud Webbike, et ladite au moins une page Webbike est synchronisée avec au moins un document exprimé selon un langage de type "markup" d'au moins une source de données, ledit au moins un document comprenant lui-même au moins un n#ud d'un langage de type "markup", ladite synchronisation permettant à un n#ud Webbike de se positionner sur un n#ud d'un langage de type "markup" afin d'en extraire des données brutes en vue de ladite création d'objets.
Dans toute la suite du document, un tel second langage spécifique est appelé langage Webbike : le langage Webbike permet de créer des objets SIDL et d'initialiser la valeur de leurs attributs, à partir d'informations contenues dans une source de données d'un langage de type "markup" Le langage Webbike permet de décrire un service complet. Par conséquent, une page Webbike donnée peut contenir la description de plusieurs documents exprimés selon un langage de type
<Desc/Clms Page number 17>
"markup" associés, par exemple de plusieurs pages HTML quelle que soit l'adresse du serveur qui les fournit.
Le principe d'un tel langage Webbike est d'indiquer au module de création d'objets appelé module Webbike, comment rechercher de l'information dans les pages HTML, ou dans les documents XML, par exemple. Dans ce dessein, de nombreux n#uds Webbike (aussi appelés tags Webbike) permettent de se synchroniser avec la source d'un langage de type "markup" considérée. La synchronisation permet au module Webbike de se positionner sur un n#ud d'un langage de type "markup", et d'en extraire des informations, telles que la valeur de ses attributs, par exemple, afin de les affecter aux membres d'objets SIDL.
De façon avantageuse, au sein dudit module Webbike, à la réception d'une demande d'au moins un premier objet, ladite sous-fonction d'extraction permet en outre de renseigner le contenu d'au moins un membre d'au moins un second objet, distinct dudit au moins un premier objet, lorsque des données brutes permettant de renseigner ledit contenu sont présentes au sein dudit document avec lequel est synchronisé ladite au moins une page Webbike.
Ainsi, lorsque le module de création d'objets selon l'invention accède, par exemple, à une page Web, il crée, au moins partiellement, tous les objets susceptibles d'être créés à partir des informations contenues dans cette page Web.
La sous-fonction d'extraction extrait donc toutes les données brutes permettant de renseigner le contenu des membres d'objets, y compris des objets sur lesquels la demande traitée ne porte pas.
De cette façon, le module de création d'objets selon l'invention optimise l'accès aux sources de données, en ne parcourant et analysant qu'une seule fois chacune des pages Web, ou des documents XML contenus dans les sources de données. À titre d'exemple, le module de création d'objets accède à une page Web donnée pour créer un objet "film" : extrait alors également les données brutes contenues dans la page et permettant de renseigner au moins certains des membres des objets "metteur en scène" et "festival de cinéma".
<Desc/Clms Page number 18>
Selon une caractéristique avantageuse de l'invention, il existe au moins les trois types de n#uds Webbike suivants : des n#uds Webbike de type synchronisation, permettant de rechercher un n#ud d'un langage de type "markup" ou une "frame" d'un n#ud d'un langage de type "markup" dans ledit au moins un document exprimé selon un langage de type "markup", afin de se positionner sur ledit n#ud d'un langage de type "markup" ou sur ladite "frame" ; des n#uds Webbike de type structure, permettant de définir au moins une condition d'exécution desdits n#uds Webbike de type synchronisation ; des n#uds Webbike de type commande, permettant de mettre en #uvre au moins une opération prédéterminée après s'être positionné sur ledit n#ud d'un langage de type "markup" ou sur ladite "frame".
L'ensemble des n#uds Webbike constitue un arbre d'instructions Webbike commandant un interpréteur pour permettre de "naviguer" au sein de la source de données analysée. Une telle navigation est déclenchée par la réception, par le module Webbike, d'une demande de création d'objets.
Il existe, selon l'invention, de nombreux n#uds de type synchronisation permettant de se synchroniser sur un n#ud d'un langage de type "markup" de la page ou du document analysé (e) le module de création d'objets. On peut citer, à titre d'exemple, un n#ud Webbike du type permettant de se synchroniser sur le prochain commentaire HTML, ou un n#ud Webbike du type permettant de conditionner une synchronisation sur le contenu d'un n#ud d'un langage de type "markup". Cette condition de synchronisation peut notamment consister à effectuer une recherche d'expressions régulières au sein du contenu dudit n#ud d'un langage de type "markup". Il est à noter qu'une telle recherche d'expressions régulières est également utilisée, au sein d'une page Web, dans le système de publication multi - terminal "Portal - To - Go", mais dans un tout autre but (recherche directe de motifs dans une page, sans respect de l'arborescence de la page, et non pas synchronisation sur les n#uds HTML de cette page, dans le dessein d'extraire les données brutes contenues dans chacun des
<Desc/Clms Page number 19>
noeuds).Avantageusement, il existe en outre au moins un des types de n#uds Webbike suivants: - des n#uds Webbike du type permettant la définition d'une sous-fonction d'extraction ; (tag Webbike) - des n#uds Webbike du type permettant l'indication du ou des objet(s) utilisé(s) dans une sous-fonction d'extraction ; (tag implements) des n#uds Webbike du type permettant la définition d'une page Webbike ; (tag page) - des n#uds Webbike du type pouvant être réutilisés avec éventuellement une liste de paramètres ; (tag method) des n#uds Webbike du type permettant la déclaration des paramètres d'une page ou d'un n#ud réutilisable ; (tag param-list) des n#uds Webbike du type permettant d'appeler une autre page Webbike sans se synchroniser sur un n#ud d'un langage de type "markup" ; link) des n#uds Webbike du type permettant d'appeler un n#ud de type réutilisable ; (tag call) des n#uds Webbike du type permettant de faire le lien vers une autre page
Webbike ; (tag action) - des n#uds Webbike du type permettant la définition d'une URL dynamique pour une page HTML ; (tag dynamic-url) des n#uds Webbike du type permettant d'affecter une valeur à un paramètre ; (tag param) - des n#uds Webbike du type permettant de répéter une séquence d'au moins un n#ud Webbike ; (tag multiple) - des n#uds Webbike du type permettant d'inclure au moins une commande dans un emplacement normalement non autorisé d'une séquence d'au moins un n#ud Webbike ; (tag block) - des n#uds Webbike du type permettant de définir au moins deux façons de se synchroniser selon le contenu d'un document ; (tag switch)
<Desc/Clms Page number 20>
des n#uds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un n#ud Webbike. (tag if/else)
On présente, en annexe 6, des exemples de la syntaxe associée à certains des n#uds Webbike décrits ci-dessus.
De façon avantageuse, lesdits n#uds Webbike de type commande appartiennent au groupe comprenant : - des n#uds Webbike du type permettant de définir un bloc d'au moins une commande associé à un n#ud (tag Webbike) du type permettant la définition d'une sous-fonction d'extraction ; (tag command) - des n#uds Webbike du type permettant l'extraction du contenu textuel d'un n#ud d'un langage de type "markup" ; body) - des n#uds Webbike du type permettant l'extraction d'au moins un attribut du n#ud d'un langage de type "markup" courant ; (tag attributes) - des n#uds Webbike du type permettant de désigner une valeur constante ; (tag constant) - des n#uds Webbike du type permettant d'assurer des fonctions de transformation des informations extraites d'un fichier exprimé selon un langage de type "markup". (function - substring, function - wordextract, function - check - url, function-java)
Selon une technique avantageuse de l'invention, ladite au moins une commande, d'un bloc défini par un n#ud Webbike, appartient au groupe comprenant : les commandes de création d'objets ; les commandes de modification d'au moins un membre d'un objet.
Il existe ainsi, notamment, une commande de création d'un nouvel objet SIDL, une commande permettant de mettre à jour les membres d'un objet SIDL, et une commande permettant d'ajouter du texte à un membre d'objet SIDL.
Avantageusement, il existe au moins les deux types de page Webbike suivants :
<Desc/Clms Page number 21>
des pages Webbike statiques, analysées au lancement de ladite sous- fonction d'extraction ; des pages Webbike dynamiques, accessibles à partir d'une autre page
Webbike par un n#ud Webbike d'un type particulier, dit lien Webbike.
Ainsi, les pages statiques ont une URL fixe, spécifiée dans un n#ud Webbike donné, appelé n#ud "page", et sont analysées au lancement de l'application. Il faut généralement au moins une page statique au sein d'un service.
Les pages dynamiques sont atteintes à l'aide d'un lien Webbike. Une page dynamique peut définir des paramètres permettant de passer des objets de page en page. Un paramètre peut être un objet simple, comme une chaîne de caractères, ou un objet SIDL.
De façon avantageuse, il existe au moins un n#ud Webbike de type synchronisation spécifique permettant de rechercher un n#ud d'un langage de type "markup" prédéterminé, afin de se positionner sur ledit n#ud d'un langage de type "markup" prédéterminé, et, en outre, un n#ud Webbike de type synchronisation générique permettant de rechercher un n#ud d'un langage de type "markup" non - prédéterminé mais spécifié en paramètre, afin de se positionner sur ledit n#ud d'un langage de type "markup" non - prédéterminé.
En effet, les langages de type "markup", tels que XML, WML ou HTML sont trop riches pour pouvoir fournir un n#ud de synchronisation Webbike pour chaque n#ud d'un langage de type "markup" existant. Afin de ne pas surcharger inutilement le langage Webbike, il existe, selon l'invention, un n#ud Webbike de type synchronisation générique, qui permet de se synchroniser sur n'importe quel n#ud d'un langage de type "markup", à condition de préciser le nom de l'élément sur lequel on veut se synchroniser.
Préférentiellement, au moins certains des n#uds de type synchronisation tiennent compte de conditions d'extraction portant sur des attributs et/ou sur un contenu textuel et/ou sur au moins un n#ud fils d'un n#ud d'un langage de type "markup" trouvé.
<Desc/Clms Page number 22>
Si plusieurs n#uds imbriqués répondent aux critères établis dans les conditions d'extraction, le premier n#ud rencontré est généralement retenu.
De façon préférentielle, ledit module Webbike met en #uvre une fonction de gestion des cookies.
Ainsi, les cookies envoyés par un serveur HTTP lors de la récupération d'une page HTML sont stockés au niveau du module Webbike. Ils sont renvoyés automatiquement par le module Webbike lorsqu'il accède à des pages qui correspondent au domaine du cookie. Certains sites Web dépendant de la gestion des cookies, il est important d'identifier la ressource qui provoque l'émission du cookie, afin d'y accéder à partir du module Webbike au moment opportun.
Dans un mode de réalisation avantageux de l'invention, au moins l'un desdits premier et second langages spécifiques est construit à l'aide d'un langage du type XML.
De manière avantageuse, ledit langage de type "markup" appartient au groupe comprenant : les langages de type XML (en anglais "Extended Markup Language") ; les langages de type HTML (en anglais "HyperText Markup Language") ; les langages de type SGML (en anglais "Standard Generalized Markup
Language") et dérivés ; les langages de type WML (en anglais "Wireless Markup Language").
L'invention concerne également un procédé de mise en #uvre d'un système selon l'une quelconque des revendications 1 à 26, caractérisé en ce qu'il comprend les étapes suivantes : un terminal émet une requête relative à une application donnée à destination dudit système ; pour élaborer une réponse à ladite requête, ledit module de génération de réponse émet une demande d'au moins un objet à destination dudit au moins un module de création d'objets, de façon à renseigner la pluralité de contextes de ladite application ;
<Desc/Clms Page number 23>
ledit au moins un module de création d'objets crée ledit au moins un objet et le renvoie audit module de génération de réponse ; ledit module de génération de réponse génère une réponse sous un format de présentation générique, en mettant en #uvre ladite navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; ledit module de présentation reçoit dudit module de génération de réponse ladite réponse sous un format de présentation générique et la transforme en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête ; ledit système envoie ladite réponse sous un format de présentation spécifique audit terminal.
Avantageusement, ledit procédé est itératif, et la réponse à une requête donnée dépend de ladite politique de navigation et d'au moins une requête et/ou réponse précédente.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un synoptique des différents types de terminaux pouvant bénéficier d'un système de publication multi - terminal selon l'invention ; - la figure 2 illustre l'architecture générale d'un système de publication multi - terminal vers les terminaux présentés en figure 1 ; - la figure 3 présente un synoptique des différents modules mis en #uvre dans un système de publication multi - terminal selon l'invention ; - la figure 4 décrit plus précisément l'architecture du système de publication multi - terminal illustré en figure 3 ; - la figure 5 présente les différentes étapes mises en #uvre lors du traitement d'une requête adressée par un client du système de publication multi - terminal de la figure 3.
<Desc/Clms Page number 24>
Le principe général de l'invention repose sur la mise en #uvre d'un système de publication multi - terminal, reposant sur le traitement d'un service générique, indépendamment de son format dans une source de données et de sa présentation finale dans le terminal cible.
On présente, en relation avec la figure 1, un synoptique des différents types de terminaux pouvant accéder à un service, extrait par exemple d'un site Web 1, à partir d'un système de publication multi - terminal 2 selon l'invention.
On distingue, par exemple, des terminaux de types divers tels qu'un terminal de type PDA (en anglais "Personal Digital Assistant") 3 ou 4, un téléphone mobile de type WAP (en anglais "Wireless Application Protocol") 5, un terminal de téléphonie fixe 6, un terminal de type Minitel 7, ou encore tout autre type de terminal, et notamment les terminaux légers 8,9 et 10.
L'architecture générale d'un système de publication multi - terminal est présentée en figure 2. Les terminaux 3,4 et 5, déjà illustrés en figure 1, et un terminal 20 de type ordinateur personnel accèdent via un protocole du type HTTP aux données 21 extraites et diffusées sur le réseau mondial Internet ou sur tout autre réseau de type internet par le serveur Web 22.
Le terminal WAP 5 ne supportant pas le protocole de type HTTP, une passerelle WAP 23 est mise en #uvre, de façon à réaliser une interface entre le protocole de type HTTP et le protocole de type WTP utilisé sur le réseau mobile.
On présente désormais, en relation avec la figure 3, les différents modules mis en #uvre dans un système de publication multi - terminal selon l'invention, dans le cas particulier où les sources de données mises en #uvre sont des sites Web composés d'une ou plusieurs page(s) HTML.
Un tel système de publication multi - terminal est alors composé de trois modules principaux : un module 30 de création d'objets ; un module 31de génération de réponse sous un format générique, utilisant le langage appelé MDSP ; un module 32 de présentation.
<Desc/Clms Page number 25>
Le module 30 de création d'objets met en #uvre une sous-fonction d'extraction de données contenues dans les pages HTML, en réalisant une synchronisation sur les n#uds HTML. Il crée des objets à l'aide du langage SIDL (en anglais "service Interface Definition Language"), puis les transmet au module 31 de génération de réponse.
Le module 31de génération de réponse sous un format générique met en #uvre un langage informatique basé sur un langage du type XML. Il récupère les objets SIDL créés par le module 30 de création d'objets
Le module 32 de présentation utilise des feuilles de style, spécifiques à chaque type de terminal de consultation, pour formater les données issues du module 31de génération de réponse, c'est-à-dire l'arbre XML intermédiaire fourni par le module référencé 31, selon un format lisible par le terminal - destination.
On décrit plus précisément en relation avec la figure 4 l'architecture du système de publication multi - terminal, dont les différents modules sont illustrés en figure 3.
Certaines données, contenues dans une source de données 40 (par exemple, un fichier de type XML, un site Web, une base de données, etc. ) sont extraites par un module de création d'objets 30, pour renseigner les membres de certains objets, nécessaires à la construction d'une réponse à un terminal de consultation 5. Le module 30 met en #uvre un langage spécifique, qui permet la création d'objets de type SIDI (en anglais "Service Interface Definition Language").
Les objets SIDL sont ensuite transmis au module 31 de génération de réponse sous un format de présentation générique, qui élabore une réponse sous forme d'un arbre de type XML.
Un tel arbre XML est ensuite traité par un module de présentation, qui met en #uvre un ensemble de feuilles de style 32. Chaque feuille de style est associée à un type de terminal de consultation, et permet de définir les critères de présentation spécifiques à chaque type de terminal. On peut ainsi envisager que le module de présentation utilise une feuille de style caractéristique des terminaux de
<Desc/Clms Page number 26>
type WAP, une feuille de style caractéristique des terminaux de type Minitel, une feuille de style caractéristique des terminaux de type PAD, etc.
Le module de présentation 32 peut ensuite fournir, au terminal 5 ayant émis une requête à destination du système de publication multi - terminal selon l'invention, une réponse dont le contenu et la présentation sont adaptés au type du terminal de consultation 5 (ici, un terminal de type WAP).
Les modules 30 de création d'objets, 31 de génération de réponse, et 32 de présentation fonctionnent donc indépendamment, d'une part, de la nature de la source de données 40, et d'autre part, du type du terminal de consultation 5.
On décrit désormais, en relation avec la figure 5, les différentes étapes mises en #uvre lors du traitement, par le système de publication multi - terminal, d'une requête provenant d'un terminal client.
Au cours d'une première étape, un client 50 disposant d'un terminal adapté au système de publication multi - terminal selon l'invention, émet une requête 51 d'accès à un ensemble d'informations. Par exemple, le client 50 peut demander l'accès à un site Web donné, ou à un ensemble d'informations contenues dans une base de données particulière. Le client 50 peut encore demander des informations que le système de publication multi - terminal selon l'invention doit, par exemple, partiellement extraire d'un site Web, partiellement extraire d'une base de données, et partiellement générer en mettant en #uvre un module de type java.
On peut ainsi envisager que le client 50 souhaite, par exemple, connaître la liste des événements culturels qui auront lieu dans une ville donnée au cours des prochains mois.
Selon le mode de réalisation illustré en figure 5, le système de publication multi - terminal selon l'invention comprend, outre les modules présentés en figures 3 et 4, un module d'interfaçage 59, permettant d'intercepter et d'analyser la requête 51.
Après analyse de la requête 51, le module d'interfaçage 59 détermine le type de terminal utilisé par le client 50 pour émettre la requête 51, de façon à ce que le système de publication multi - terminal selon l'invention puisse transmettre
<Desc/Clms Page number 27>
au client 50 une réponse dont le contenu et la présentation sont adaptés au type de terminal de consultation. Le module d'interfaçage 59 transmet ensuite sa requête au module de génération de réponse sous un format générique 31, au cours d'une étape référencée 52.
Au cours d'une étape référencée 53, le module de génération de réponse 31 émet à son tour une requête à destination de l'ensemble de modules de création d'objets 30, de manière à requérir la création des objets nécessaires à la construction d'une réponse au client 50.
L'ensemble des modules de création d'objets 30 interroge un ensemble de sources de données, afin d'en extraire les informations demandées par le module de génération de réponse 31. Par exemple, un module de type java 302 génère certains objets SIDL, un module 301 de création d'objets, appelé Webbike, extrait des objets SIDL d'un ou plusieurs sites Web par synchronisation sur les tags HTML, et un module de création d'objets 302 créé des objets SIDL à partir des données brutes contenues dans une ou plusieurs bases de données.
Au cours d'une étape référencée 54, l'ensemble des modules de création d'objets 30 transmet au module de génération de réponse sous un format générique 31 les objets SIDL créés en réponse à la requête 53, ainsi que des objets SIDL, nécessaires à la génération d'une réponse à la requête 51 du client 50, créés précédemment par l'ensemble des modules de création d'objets 30. Par exemple, on peut envisager qu'une partie de la réponse transmise précédemment à un autre client 50 puisse être réutilisée pour l'élaboration d'une réponse à la requête 51 ; dans ce cas, l'ensemble de modules de création d'objets 30 transmet au module de génération de réponse 31 les objets déjà créés précédemment, par exemple par extraction d'un site Web et/ou d'une base de données et/ou d'un module java.
Dans ce dessein, à la réception d'une requête 53, l'ensemble des modules de création d'objets 30 met en #uvre une comparaison des objets nécessaires au module de génération de réponse 31 avec une liste d'objets précédemment créés, de manière à ne mettre en #uvre les fonctions d'extraction ou de génération d'objets que pour les objets non précédemment créés.
<Desc/Clms Page number 28>
Le module de génération de réponse sous un format générique 31 met alors en #uvre une navigation au sein de la pluralité de contextes relatifs au service requis par le client 50 au cours de l'étape 51. Une telle navigation au sein des contextes, dans lesquels sont regroupés les objets SIDL fournis par les modules de création d'objets 30, permet au module de génération de réponse sous un format générique 31 d'élaborer, au cours d'une étape référencée 55, un arbre de type XML.
Le module de présentation 32 traite alors cet arbre intermédiaire XML, de manière à présenter la réponse envoyée au client 50 sous un format adapté au type de terminal de consultation. Dans ce dessein, le module de présentation 32 utilise un ensemble de feuilles de style présentées en figure 4, et regroupant les caractéristiques de présentation propres à chaque type de terminal de consultation.
Au cours d'une étape référencée 56, le module de présentation 32 envoie la réponse, sous un format de présentation spécifique au type du terminal ayant formulé la requête 51, au module de génération de réponse 31. Le module 31 retourne alors la réponse finale au module d'interfaçage 59 au cours d'une étape référencée 57.
La réponse finale, sous un format de présentation adapté au type de terminal utilisé par le client 50, est ensuite acheminée vers le terminal de consultation, au cours d'une étape référencée 58.
<Desc/Clms Page number 29>
ANNEXE 1 Composant de type "traitement" <handler action = "OK"> <on> <valid field = "selectEvt"/> </on> <do> <change-context context "pageDuResume"> <param pram="unEvenement" value="selectEvt"/> </change-context> </do> </handler> Composant de type "méthode" <method name = "uneMethode"> <param-list> <simple name = "unParametre"/> </param-list> <if condition = "unParametre EQUAL'retour"'> <previous-context> </if> <else> <else> <change-context context = "PageDAide"/> </else> </method>
<Desc/Clms Page number 30>
ANNEXE 2 Instructions de type "contenu" Instruction "contenu-item" <content-item node-name = "ville-courante"> <content-member member = "nom"/> </content-item> Instruction "contenu-défilement-action" Exemple <content-action-scroll name = "scrollEvenements"> Arbre XML généré <eop-action type = "scroll" direction = "previous" name = "name" value = "5.12-1" url = "hostaddress/1-1-1-1?a=5.12-1" uri = "hostaddress/1-1-1-1"/> <eop-action type = "scroll" direction = "next" name = "name" value = "5.12-2" url = "hostaddress/1-1-1-1?a=5.12-2" uri = "hostaddressl 1 - 1 - 1 - 1 "/>
<Desc/Clms Page number 31>
ANNEXE 3 Instructions de type "manipulation de variables" Instruction "liste" <list name = "uneListe" class = "C~Ville"/> Instruction "créer" <create variable = "listeEvt" constructor = "StringEtCat"> <param param = "a~string" value = "'Paris"'/> <param param = "a~cat" value = "CatégorieCourante"/> </create>
<Desc/Clms Page number 32>
ANNEXE 4 Instructions de type "navigation" Instruction "changer-contexte" <change-context context = "Evenement" entrypoint = "fromLieux"> <param param = "unLieu" value = "lieuSelectionne"/> </change-context> Instruction "changer-service" <change-service service = "ErrorService" entrypoint = "BadName"> <param param = "a~msg" value = "' le nom ' CAT inputNAME CAT ' est inconnu '"/> </change-service>
<Desc/Clms Page number 33>
ANNEXE 5 Instruction de type "utilisation" Instruction "sinon" <if condition = "TERMINAL. Software.langage EQUAL'html' "> <change-context context = "aideHTML"/> </if> <else> <change-context context ="AideVDXML"/> </else> Instruction "parametre-liste" <param-list> <simple name = "unPremierParam"/> <object name = "unSecondParam" class = "C~Ville"/> </param-list>
<Desc/Clms Page number 34>
ANNEXE 6 N#uds Webbike du type permettant la définition d'une sous-fonction d'extraction : <WebBike service="nouba" javascript="on"> <!- -liste des implements - -> <!- -liste de page - -> <!- -liste de method - -> </WebBike> N#uds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un n#ud Webbike : <if condition ="expression"> [<command>] <!- - instructions WebBike- - > </if> <else> [<command>] <!- - instructions WebBike- - > </else> N#uds Webbike du type permettant la définition d'une URL dynamique pour une page HTML : <dynamic-url base="http://..."[method="post"]> <!- - liste des objets passés en paramètres à la page (liste de <param>).
Ici le tag param associe un nom de paramètre de la page avec un
Nom de paramètre de la requête (paramètre d'un constructeur
D'objet SIDL) - -> <!- - liste des paramètres à passer au CGI (liste de <url-param>). - -> </dynamic-url>
<Desc/Clms Page number 35>
N#uds Webbike du type permettant la définition d'une page Webbike : <page name="root" [url="http://www.nouba.voilà.fr"] [parse-mode="service"]> [<param-list>] [<command>] <!- -liste de <dynamic-url> - -> <!- - instructions WebBike- - > </page>

Claims (30)

  1. REVENDICATIONS 1. Système de publication multi - terminal (2), du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux (3-10), selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations (40), caractérisé en ce qu'il comprend : au moins un module de création d'objets (30,301-303), permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites de ladite au moins une source d'informations et/ou générées par ledit au moins un module de création d'objets ; un module (31) de génération de réponse sous un format de présentation générique, en réponse à une requête (51) formulée par un terminal et relative à une application donnée, ladite application étant définie, au sein dudit module de génération de réponse, par une pluralité de contextes et une politique de navigation parmi lesdits contextes, chaque contexte comprenant au moins une action et/ou au moins un objet, créé par ledit au moins un module de création d'objets, ladite réponse résultant d'une navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; - un module de présentation (32), permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.
  2. 2. Système selon la revendication 1, caractérisé en ce que ladite réponse sous un format de présentation générique est un arbre de type XML ou de type SGML.
  3. 3. Système selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend en outre un module d'interfaçage (59) permettant d'intercepter et d'analyser ladite requête (51) formulée par un terminal, de manière à : identifier le type dudit terminal ; créer une nouvelle requête (52), sous un format de requête générique, destinée audit module de génération de réponse.
    <Desc/Clms Page number 37>
  4. 4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que chaque objet comprend au moins un membre relatif à la structure dudit objet et au moins un constructeur, ledit au moins un constructeur permettant audit au moins un module (30) de création d'objets de renseigner le contenu dudit au moins un membre.
  5. 5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit au moins un module (30) de création d'objets appartient au groupe comprenant : un module (301) de création d'objets, appelé module Webbike, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une source de données contenant au moins un document exprimé selon un langage de type "markup" ; un module (303) de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une base de données du type SQL ; un module (302) de création d'objets, construit à partir d'un langage du type java, permettant de fournir au moins une fonction de création d'objets à partir de données brutes générées par ledit module de création d'objets et/ou extraites d'au moins une source d'informations prédéterminées.
  6. 6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit module (32) de présentation est construit à l'aide d'un langage du type XSL.
  7. 7. Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'au sein dudit module (31) de génération de réponse, ladite au moins une application est composée, selon un premier langage spécifique, d'un conteneur service, décrivant ledit service, et d'au moins un conteneur contexte, correspondant chacun à une étape de ladite navigation.
  8. 8. Système selon la revendication 7, caractérisé en ce qu'un conteneur est composé d'au moins un composant, permettant de regrouper au moins une instruction.
    <Desc/Clms Page number 38>
  9. 9. Système selon la revendication 8, caractérisé en ce qu'il met en #uvre six types de composants : des composants de type "point d'entrée", permettant de décrire une première pluralité d'opérations que ledit module de génération de réponse doit effectuer au lancement de l'exécution d'un conteneur service ou d'un conteneur contexte ; - des composants de type "attributs", permettant de décrire une pluralité de variables utilisables dans ledit conteneur courant ; - des composants de type "méthode", permettant de regrouper une pluralité desdites au moins une instruction au sein d'une procédure ; - des composants de type "imports", permettant de décrire ledit au moins un objet nécessaire audit module de génération de réponse, pour générer ladite réponse à ladite requête relative à une application donnée ; - des composants de type "traitement", permettant de décrire une seconde pluralité d'opérations que ledit module de génération de réponse doit effectuer en réponse à une action réalisée par un terminal ; - des composants de type "contenu", permettant de décrire lesdites informations fournies à un terminal au sein de ladite réponse et/ou de décrire ladite au moins une action que peut réaliser ledit terminal à une étape de ladite navigation donnée.
  10. 10. Système selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il met en #uvre les quatre types d'instructions suivants : des instructions de type "contenu", permettant de générer une partie de ladite réponse sous un format de présentation générique ; - des instructions de type "manipulation de variables", permettant de déclarer et/ou de manipuler au moins une variable ; - des instructions de type "navigation", permettant de changer de contexte courant et/ou d'application courante ; des instructions de type "utilisation", pouvant être utilisées par des instructions et/ou des composants.
    <Desc/Clms Page number 39>
  11. 11. Système selon la revendication 10, caractérisé en ce que lesdites instructions de type "contenu" appartiennent au groupe comprenant : - une instruction "contenu-littéral", permettant de décrire une chaîne de caractères de ladite réponse sous un format générique ; - une instruction "contenu-objet", permettant de décrire un objet ; - une instruction "contenu-liste", permettant de décrire une liste d'objets ; - une instruction "contenu-item", permettant de décrire un élément d'une liste ; - une instruction "contenu-membre", permettant de décrire un membre d'un objet ; - une instruction "contenu-sélection ", permettant de sélectionner un item dans une liste ; - une instruction "contenu-sélection-multiple", permettant de sélectionner au moins un item dans une liste ; - une instruction "contenu-entrée", permettant de décrire un item de type "entrée" par lequel ledit terminal ayant formulé ladite requête peut entrer une valeur ; - une instruction "contenu-défilement-action ", permettant de se déplacer au sein d'une liste ; - une instruction "contenu-action", permettant de décrire une action ; - une instruction "contenu-action-changement-de-contexte", permettant de décrire une action qui permet audit terminal ayant formulé ladite requête de changer de contexte ; - une instruction "contenu-action-contexte-précédent", permettant audit terminal ayant formulé ladite requête de revenir au contexte précédent.
  12. 12. Système selon l'une quelconque des revendications 10 et 11, caractérisé en ce que lesdites instructions de type "manipulation de variables" appartiennent au groupe comprenant : une instruction "objet", permettant de déclarer une variable de type "objet" ;
    <Desc/Clms Page number 40>
    une instruction "liste", permettant de déclarer une variable de type "liste" ; une instruction "simple", permettant de déclarer une variable de type "simple", distinct dudit type "objet" et dudit type "liste " ; une instruction "créer", permettant de construire un objet ou une liste d'objets ; une instruction "établissement", permettant d'affecter une valeur à une variable ; une instruction "liste-déplacer", permettant de déplacer un pointeur courant d'une liste, en spécifiant un pas de déplacement ; une instruction "liste-déplacer-vers", permettant de déplacer un pointeur courant d'une liste en spécifiant une nouvelle position dudit pointeur.
  13. 13. Système selon l'une quelconque des revendications 10 à 12, caractérisé en ce que lesdites instructions de type "navigation" appartiennent au groupe comprenant : - une instruction "changer-contexte", permettant d'instancier un nouveau contexte ; - une instruction "changer-service", permettant d'instancier un nouveau service ; - une instruction " contexte-précédent", permettant de revenir au contexte précédent dans le service courant ; - une instruction "service-précédent", permettant de revenir au contexte précédent avec le dernier contexte dudit service.
  14. 14. Système selon l'une quelconque des revendications 10 à 13, caractérisé en ce que lesdites instructions de type "utilisation" appartiennent au groupe comprenant : une instruction "appel", permettant d'appeler un composant "méthode" dans le contexte ou le service courant ; une instruction "si", permettant d'établir une condition sur un ensemble d'instructions ;
    <Desc/Clms Page number 41>
    une instruction "sinon", faisant suite à une instruction "si" et permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon-si", faisant suite à une instruction "si" et permettant d'établir au moins une autre condition sur ledit ensemble d'instructions ; une instruction "exécuter-contenu", permettant de générer une présentation desdites informations décrites dans un composant "contenu" ; une instruction "sidl-import", permettant de spécifier un objet à utiliser dans le service courant ; une instruction "paramètre-liste", permettant de regrouper des déclarations de paramètres ; une instruction "paramètre", permettant de spécifier la valeur d'un paramètre ; une instruction "faire", permettant de regrouper dans un composant du type "traitement" des actions à effectuer au lancement de l'exécution d'un contexte ; une instruction "sur", permettant de regrouper des conditions devant être validées pour qu'un composant du type "traitement" s'exécute.
  15. 15. Système selon l'une quelconque des revendications 1 à 14, caractérisé en ce qu'à la réception par ledit au moins un module (30) de création d'objets d'une demande d'au moins un objet, ladite demande venant dudit module (31) de génération de réponse, ladite au moins une fonction de création d'objets met en #uvre au moins une sous-fonction d'extraction, permettant de renseigner le contenu d'au moins un membre relatif à la structure dudit au moins un objet.
  16. 16. Système selon la revendication 15, caractérisé en ce que ladite au moins une fonction de création d'objets comprend en outre une sous-fonction de comparaison dudit au moins un objet sur lequel porte ladite demande avec une liste d'objets préalablement au moins partiellement créés, de façon à ne mettre en #uvre ladite au moins une sous-fonction d'extraction que pour la création d'objets non préalablement créés et/ou pour compléter des objets préalablement partiellement créés.
    <Desc/Clms Page number 42>
  17. 17. Système selon l'une quelconque des revendications 15 et 16, caractérisé en ce qu'au sein dudit module Webbike (301), chaque sous-fonction d'extraction est composée, selon un second langage spécifique, d'au moins une page Webbike comprenant au moins un n#ud Webbike, et en ce que ladite au moins une page Webbike est synchronisée avec au moins un document exprimé selon un langage de type "markup" d'au moins une source de données, ledit au moins un document comprenant lui-même au moins un n#ud d'un langage de type "markup", ladite synchronisation permettant à un n#ud Webbike de se positionner sur un n#ud d'un langage de type "markup" afin d'en extraire des données brutes en vue de ladite création d'objets.
  18. 18. Système selon les revendications 4 et 17, caractérisé en ce qu'au sein dudit module Webbike, à la réception d'une demande d'au moins un premier objet, ladite sous-fonction d'extraction permet en outre de renseigner le contenu d'au moins un membre d'au moins un second objet, distinct dudit au moins un premier objet, lorsque des données brutes permettant de renseigner ledit contenu sont présentes au sein dudit document avec lequel est synchronisé ladite au moins une page Webbike.
  19. 19. Système selon l'une quelconque des revendications 17 et 18, caractérisé en ce qu'il existe au moins les trois types de n#uds Webbike suivants : des n#uds Webbike de type synchronisation, permettant de rechercher un n#ud d'un langage de type "markup" ou une "frame" d'un n#ud d'un langage de type "markup" dans ledit au moins un document exprimé selon un langage de type "markup", afin de se positionner sur ledit n#ud d'un langage de type "markup" ou sur ladite "frame" ; des n#uds Webbike de type structure, permettant de définir au moins une condition d'exécution desdits n#uds Webbike de type synchronisation ; des n#uds Webbike de type commande, permettant de mettre en #uvre au moins une opération prédéterminée après s'être positionné sur ledit n#ud d'un langage de type "markup" ou sur ladite "frame".
    <Desc/Clms Page number 43>
  20. 20. Système selon la revendication 19, caractérisé en ce qu'il existe en outre au moins un des types de n#uds Webbike suivants: des n#uds Webbike du type permettant la définition d'une sous-fonction d'extraction ; - des n#uds Webbike du type permettant l'indication du ou des objet(s) utilisé(s) dans une sous-fonction d'extraction ; des n#uds Webbike du type permettant la définition d'une page Webbike ; - des n#uds Webbike du type pouvant être réutilisés avec éventuellement une liste de paramètres ; des n#uds Webbike du type permettant la déclaration des paramètres d'une page ou d'un n#ud réutilisable ; des n#uds Webbike du type permettant d'appeler une autre page Webbike sans se synchroniser sur un n#ud d'un langage de type "markup" ; - des n#uds Webbike du type permettant d'appeler un n#ud de type réutilisable ; - des n#uds Webbike du type permettant de faire le lien vers une autre page
    Webbike ; - des n#uds Webbike du type permettant la définition d'une URL dynamique pour une page HTML ; - des n#uds Webbike du type permettant d'affecter une valeur à un paramètre ; des n#uds Webbike du type permettant de répéter une séquence d'au moins un n#ud Webbike ; - des n#uds Webbike du type permettant d'inclure au moins une commande dans un emplacement normalement non autorisé d'une séquence d'au moins un n#ud Webbike ; des n#uds Webbike du type permettant de définir au moins deux façons de se synchroniser selon le contenu d'un document ; des n#uds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un n#ud Webbike.
    <Desc/Clms Page number 44>
  21. 21. Système selon la revendication 19, caractérisé en ce que lesdits n#uds Webbike de type commande appartiennent au groupe comprenant : - des n#uds Webbike du type permettant de définir un bloc d'au moins une commande associé à un n#ud du type permettant la définition d'une sous- fonction d'extraction ; - des n#uds Webbike du type permettant l'extraction du contenu textuel d'un n#ud d'un langage de type "markup" ; - des n#uds Webbike du type permettant l'extraction d'au moins un attribut du n#ud d'un langage de type "markup" courant ; - des n#uds Webbike du type permettant de désigner une valeur constante ; - des n#uds Webbike du type permettant d'assurer des fonctions de transformation des informations extraites d'un fichier d'un langage de type "markup".
  22. 22. Système selon la revendication 21, caractérisé en ce que ladite au moins une commande, d'un bloc défini par un n#ud Webbike, appartient au groupe comprenant : les commandes de création d'objets ; - les commandes de modification d'au moins un membre d'un objet.
  23. 23. Système selon l'une quelconque des revendications 17 à 22, caractérisé en ce qu'il existe au moins les deux types de page Webbike suivants : des pages Webbike statiques, analysées au lancement de ladite sous- fonction d'extraction ; - des pages Webbike dynamiques, accessibles à partir d'une autre page
    Webbike par un n#ud Webbike d'un type particulier, dit lien Webbike.
  24. 24. Système selon l'une quelconque des revendications 19 à 23, caractérisé en ce qu'il existe au moins un n#ud Webbike de type synchronisation spécifique permettant de rechercher un n#ud d'un langage de type "markup" prédéterminé, afin de se positionner sur ledit n#ud d'un langage de type "markup" prédéterminé, et, en outre, un n#ud Webbike de type synchronisation générique permettant de rechercher un n#ud d'un langage de type "markup" non - prédéterminé mais
    <Desc/Clms Page number 45>
    spécifié en paramètre, afin de se positionner sur ledit n#ud d'un langage de type "markup" non - prédéterminé.
  25. 25. Système selon l'une quelconque des revendications 19 à 24, caractérisé en ce que au moins certains des n#uds de type synchronisation tiennent compte de conditions d'extraction portant sur des attributs et/ou sur un contenu textuel et/ou sur au moins un n#ud fils d'un n#ud d'un langage de type "markup" trouvé.
  26. 26. Système selon l'une quelconque des revendications 5 à 25, caractérisé en ce que ledit module Webbike met en #uvre une fonction de gestion des cookies.
  27. 27. Système selon les revendications 7 et 17, caractérisé en ce qu'au moins l'un desdits premier et second langages spécifiques est construit à l'aide d'un langage du type XML.
  28. 28. Système selon l'une quelconque des revendications 17 à 27, caractérisé en ce que ledit langage de type "markup" appartient au groupe comprenant : les langages de type XML (en anglais "Extended Markup Language") ; - les langages de type HTML (en anglais "HyperText Markup Language") ; les langages de type SGML (en anglais "Standard Generalized Markup
    Language") et dérivés ; - les langages de type WML (en anglais "Wireless Markup Language").
  29. 29. Procédé de mise en #uvre d'un système selon l'une quelconque des revendications 1 à 28, caractérisé en ce qu'il comprend les étapes suivantes : un terminal (3-10) émet une requête (51) relative à une application donnée à destination dudit système (2) ; pour élaborer une réponse à ladite requête, ledit module (31) de génération de réponse émet une demande d'au moins un objet à destination dudit au moins un module (30) de création d'objets, de façon à renseigner la pluralité de contextes de ladite application ; ledit au moins un module de création d'objets crée ledit au moins un objet et le renvoie audit module de génération de réponse ;
    <Desc/Clms Page number 46>
    ledit module de génération de réponse génère une réponse sous un format de présentation générique, en mettant en #uvre ladite navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; ledit module de présentation (32) reçoit dudit module de génération de réponse ladite réponse sous un format de présentation générique et la transforme en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête ; ledit système envoie ladite réponse sous un format de présentation spécifique audit terminal.
  30. 30. Procédé selon la revendication 29, caractérisé en ce que ledit procédé est itératif, et en ce que la réponse à une requête donnée dépend de ladite politique de navigation et d'au moins une requête et/ou réponse précédente.
FR0007073A 2000-05-31 2000-05-31 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant Expired - Fee Related FR2809844B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0007073A FR2809844B1 (fr) 2000-05-31 2000-05-31 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
AU2001262431A AU2001262431A1 (en) 2000-05-31 2001-05-16 Multiterminal publishing system and corresponding method for using same
EP01936548A EP1285361A1 (fr) 2000-05-31 2001-05-16 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
PCT/FR2001/001500 WO2001093094A1 (fr) 2000-05-31 2001-05-16 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
US10/297,221 US20030158894A1 (en) 2000-05-31 2001-05-16 Multiterminal publishing system and corresponding method for using same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0007073A FR2809844B1 (fr) 2000-05-31 2000-05-31 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant

Publications (2)

Publication Number Publication Date
FR2809844A1 true FR2809844A1 (fr) 2001-12-07
FR2809844B1 FR2809844B1 (fr) 2002-11-22

Family

ID=8850897

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0007073A Expired - Fee Related FR2809844B1 (fr) 2000-05-31 2000-05-31 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant

Country Status (5)

Country Link
US (1) US20030158894A1 (fr)
EP (1) EP1285361A1 (fr)
AU (1) AU2001262431A1 (fr)
FR (1) FR2809844B1 (fr)
WO (1) WO2001093094A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1345443A2 (fr) * 2002-03-07 2003-09-17 Chello Broadband NV Appareil d'amélioration de la mise en format de données de télévision interactive

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6978301B2 (en) * 2000-12-06 2005-12-20 Intelliden System and method for configuring a network device
US7054946B2 (en) * 2000-12-06 2006-05-30 Intelliden Dynamic configuration of network devices to enable data transfers
US8219662B2 (en) 2000-12-06 2012-07-10 International Business Machines Corporation Redirecting data generated by network devices
US7150037B2 (en) * 2001-03-21 2006-12-12 Intelliden, Inc. Network configuration manager
US8296400B2 (en) 2001-08-29 2012-10-23 International Business Machines Corporation System and method for generating a configuration schema
US7065562B2 (en) * 2001-11-26 2006-06-20 Intelliden, Inc. System and method for generating a representation of a configuration schema
US6959329B2 (en) * 2002-05-15 2005-10-25 Intelliden System and method for transforming configuration commands
US20040028069A1 (en) * 2002-08-07 2004-02-12 Tindal Glen D. Event bus with passive queuing and active routing
US20040030771A1 (en) * 2002-08-07 2004-02-12 John Strassner System and method for enabling directory-enabled networking
US8010423B2 (en) * 2002-08-29 2011-08-30 International Business Machines Corporation Anticipatory mobile system service brokering and resource planning from multiple providers
US20040078457A1 (en) * 2002-10-21 2004-04-22 Tindal Glen D. System and method for managing network-device configurations
US8027843B2 (en) * 2002-11-07 2011-09-27 International Business Machines Corporation On-demand supplemental diagnostic and service resource planning for mobile systems
US20040093299A1 (en) * 2002-11-07 2004-05-13 International Business Machines Corporation System and method for coalescing information for presentation to a vehicle operator
US7447642B2 (en) * 2002-11-07 2008-11-04 International Business Machines Corporation Location based services revenue sharing and cost offsetting
US20040230681A1 (en) * 2002-12-06 2004-11-18 John Strassner Apparatus and method for implementing network resources to provision a service using an information model
US9535679B2 (en) * 2004-12-28 2017-01-03 International Business Machines Corporation Dynamically optimizing applications within a deployment server
FI117656B (fi) * 2005-02-15 2006-12-29 Lumi Interactive Ltd Sisällön optimointi vastaanottaville päätelaitteille
CN107402747B (zh) * 2016-05-20 2019-08-20 中国科学院声学研究所 一种支持多终端类型的应用页面动态生成方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049831A (en) * 1996-11-08 2000-04-11 Gte Laboratories Incorporated System for transmitting network-related information where requested network information is separately transmitted as definitions and display information
US6857102B1 (en) * 1998-04-07 2005-02-15 Fuji Xerox Co., Ltd. Document re-authoring systems and methods for providing device-independent access to the world wide web
US6055229A (en) * 1998-06-29 2000-04-25 Motorola, Inc. Method and apparatus in a wireless communication system for dynamically formatting application data to be transmitted
JP3202968B2 (ja) * 1998-06-30 2001-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション 表示制御情報生成方法及びコンピュータ
US6466232B1 (en) * 1998-12-18 2002-10-15 Tangis Corporation Method and system for controlling presentation of information to a user based on the user's condition
US6993575B2 (en) * 2000-02-22 2006-01-31 Oracle International Corporation Using one device to configure and emulate web site content to be displayed on another device
WO2001084433A1 (fr) * 2000-05-01 2001-11-08 Mobliss, Inc. Systeme permettant de conduire des enquetes electroniques

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Converting HTML to Well Formed XML With Preference Based Tag Expansion", RESEARCH DISCLOSURE, vol. 42, no. 423, 1 July 1999 (1999-07-01), Havant, UK, article No. 423111, XP002163912 *
BICKMORE T W ET AL: "Digestor: device-independent access to the World Wide Web", COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 29, no. 8-13, 1 September 1997 (1997-09-01), pages 1075 - 1082, XP004095305, ISSN: 0169-7552 *
FREYTAG C ET AL: "Resource adaptive WWW access for mobile applications", COMPUTERS AND GRAPHICS,GB,PERGAMON PRESS LTD. OXFORD, vol. 23, no. 6, December 1999 (1999-12-01), pages 841 - 848, XP004187832, ISSN: 0097-8493 *
H K W ET AL: "Object model for hypermedia applications", COMPUTER COMMUNICATIONS,NL,ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, vol. 18, no. 7, 1 July 1995 (1995-07-01), pages 475 - 485, XP004032466, ISSN: 0140-3664 *
WOOD L: "Programming the Web: the W3C DOM specification", IEEE INTERNET COMPUTING, JAN.-FEB. 1999, IEEE, USA, vol. 3, no. 1, pages 48 - 54, XP002163911, ISSN: 1089-7801 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1345443A2 (fr) * 2002-03-07 2003-09-17 Chello Broadband NV Appareil d'amélioration de la mise en format de données de télévision interactive
EP1345443A3 (fr) * 2002-03-07 2004-03-03 Chello Broadband NV Appareil d'amélioration de la mise en format de données de télévision interactive
US8424051B2 (en) 2002-03-07 2013-04-16 Upc Broadband Operations Bv Enhancement for interactive TV formatting apparatus

Also Published As

Publication number Publication date
FR2809844B1 (fr) 2002-11-22
US20030158894A1 (en) 2003-08-21
EP1285361A1 (fr) 2003-02-26
WO2001093094A1 (fr) 2001-12-06
AU2001262431A1 (en) 2001-12-11

Similar Documents

Publication Publication Date Title
FR2809844A1 (fr) Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
KR101079570B1 (ko) 검색 웹 서비스
US10747505B1 (en) API specification generation
US7823123B2 (en) Semantic system for integrating software components
US8640087B2 (en) Semantic system for integrating software components
US7467391B2 (en) Allowing client applications to programmatically access web sites
KR101004576B1 (ko) 연쇄 발견 웹 서비스
US7027975B1 (en) Guided natural language interface system and method
US20040167896A1 (en) Content management portal and method for communicating information
US20040187111A1 (en) Content management portal and method for communicating media content
Binding et al. KOS at your service: Programmatic access to knowledge organisation systems
Alarcon et al. REST web service description for graph-based service discovery
US20040167960A1 (en) Network service interceptor
Nadee et al. Towards data extraction of dynamic content from JavaScript Web applications
Lanthaler et al. Seamless integration of restful services into the web of data
Fan et al. Semantic client‐side approach for web personalization of SaaS‐based cloud services
EP1285360B1 (fr) Module de creation d&#39;objets, a partir de donnees brutes extraites d&#39;au moins une source de donnees contenant au moins un document exprime selon un langage de type &#34;markup&#34;
Mukherjee et al. U-P2P: A peer-to-peer system for description and discovery of resource-sharing communities
Bergweiler A flexible framework for adaptive knowledge retrieval and fusion for kiosk systems and mobile clients
EP4235517A1 (fr) Emballage, produit-programme informatique, système et procédé mis en uvre par ordinateur pour la transformation de données
Bieg A Web-based Tool to Semi-automatically Import Data from Generic REST APIs
Daly et al. Toward a Reference Architecture for Digital and Model-Based Engineering Information Systems
US7240126B1 (en) Method and system for parsing for use in a server and web browser
Bouougada et al. Re-engineering Web Application towards Linked Data: a Model-Based Approach.
Stoilov et al. Network of e-services.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20110131