FR2879783A1 - Procede de traitement d'un flot de donnees xml - Google Patents

Abstract

Le procédé de traitement d'un flot de données décrit dans un langage de balisage comprenant au moins une balise, comprend les étapes suivantes lors du traitement d'une balise par un des filtres de traitement :i) extraction d'un mot clé et d'une valeur associée dans une balise, définissant au moins une caractéristique du flot de données ;ii) vérification d'une condition de mémorisation ;iii) si la vérification est positive, mémorisation localement du mot clé et de la valeur associée dans une ligne de correspondance d'une table (T), de façon à servir ladite valeur suite à une requête d'obtention de cette valeur.

Description

La présente invention se rapporte au traitement d'un flot de données

décrit en langage de balisage de type XML par exemple.

XML, acronyme de eXtensible Markup Language c'est-à-dire langage à balise extensible, est un langage informatique permettant de structurer des documents grâce à des balises (Markup).

En pratique, XML est un format de description des données.

Le format XML est en passe de devenir un format standard pour stocker ou transmettre des données. En conséquence, il est nécessaire d'avoir des outils permettant de traiter ces docurents.

En effet, un document XML tel qu'il est stocké ou transmis ne permet pas un traitement efficace s'il est utilisé directement. Il est préférable de le transformer en une représentation plus adaptée aux traitements informatiques qui sont effectués dessus. Cette transformation est possible à l'aide d'un outil appelé analyseur XML (en anglais XML parser, parfois francisé en parseur XML ).

Réciproquement, un traitement informatique ne produit pas directement des données dans le format XML, mais sous forme d'une représentation plus adaptée, qui doit être transformée avant d'être stockée ou transmise. Ce processus de transformation est appelé génération de XML . Une telle génération est réalisée par un composant informatique appelé générateur XML (en anglais XML generatorou XML writer).

On connaît déjà plusieurs types de parseurs XML et de générateurs associés: les parseurs DOM (Document Object Model), les parseurs SAX (Simple API for XML) et les parseurs Pull.

Les premiers parseurs XML ont été des parseurs de type DOM. Face aux inconvénients que l'on décrira plus en détail ci-après, il est vite apparu qu'un autre mode de traitement des documents XML était nécessaire. Ainsi les parseurs à base d'événements de type SAX sont apparus. Avec ces parseurs est aussi apparue la notion de filtres XML. Plus récemment, une nouvelle forme de parseurs à base d'événements est apparue: ce sont les parseurs Pull.

Le principe d'un parseur DOM est de transformer un document XML en une représentation objet de sa structure. Ainsi, chaque élément d'un document est représenté par un objet qui décrit cet élément (son nom, son éventuel espace de nommage (namespace)...) et ses liens avec le reste du document (ses attributs, ses sous-éléments...).

Une application peut facilement parcourir une telle représentation d'un document XML et peut aussi facilement la modifier. Ainsi, pour ajouter un nouvel élément au document, il suffit de créer un nouvel objet pour le représenter et d'ajouter cet objet à la liste des sous-éléments de l'élément parent.

Une 'telle représentation peut être transformée en document XML en utilisant un générateur DOM qui va parcourir la représentation objet du document et, pour chaque objet de cette représentation, générer le fragment XML adéquat.

Le principe d'un parseur SAX est de décrire un document XML sous forme d'événements. Un parseur SAX parcourt le document XML qu'il doit traiter et, pour chaque partie de ce document, génère un événement décrivant cette partie. L'ensemble des événements générés décrit l'ensemble du document XML.

Une application utilisant un parseur SAX enregistre auprès du parseur des méthodes (appelées callback ) pour traiter les types d'événements auxquels l'application s'intéresse. Durant le parcours du document, à chaque fois que le parseur SAX génère un événement, il l'envoie à la méthode appropriée de l'application qui peut alors le traiter comme elle le souhaite.

Un générateur SAX consiste en une application spéciale fournissant des méthodes pour l'ensemble des événements possibles. Chacune des 30 méthodes est chargée de générer, pour les événements qu'elle reçoit, le fragment XML représentant cet événement.

Par conséquent, une application souhaitant générer un document XML doit générer les événements décrivant ce document.

Le principe d'un parseur Pull repose aussi sur la notion d'événement. Mais, tandis qu'un parseur SAX pousse (push en anglais) les événements vers l'application, dans le cas d'un parseur Pull (qui signifie tirer), c'est l'application qui demande les événements au parseur au fur et à mesure de ses besoins.

Un générateur Pull reçoit quant à lui des événements générés par l'application et les transforme en un document XML.

L'avantage du parseur DOM par rapport aux parseurs SAX et Pull est que la représentation complète du document est en mémoire. Ainsi, une application peut à tout moment atteindre tout endroit du document XML. Ce type de représentation permet aussi une modification très facile de l'ensemble du document XML.

Cependant, ce type de représentation présente un certain nombre 15 d'inconvénients.

Tout d'abord, la représentation en mémoire du document XML consomme de la mémoire. Si le document XML à traiter est gros, ou s'il y a de nombreux documents XML à traiter simultanément, ceci peut poser des problèmes. Cet inconvénient est particulièrement crucial pour des appareils légers comportant peu de mémoire.

Un autre inconvénient est que la représentation du document en mémoire est une représentation générique qui n'est pas forcément adaptée à l'usage que souhaite en faire l'application. Dans ce cas, l'application doit transformer cette représentation générique en une représentation qui lui est 2.5 plus adaptée, ce qui multiplie les traitements nécessaires.

Par rapport au parseur DOM, les parseurs SAX et Pull présentent l'avantage de nécessiter une quantité moins importante de mémoire: il n'y a pas nécessairement une représentation complète du document XML en mémoire. Dans le cas où une représentation en mémoire du document XML est nécessaire, elle peut être réalisée directement dans une forme adaptée aux traitements de l'application.

Dans le cas du parseur SAX, c'est le parseur qui contrôle la communication entre lui-même et l'application. Ceci peut être un inconvénient pour l'application. De plus, à cause du mode de communication, l'application doit maintenir explicitement entre deux appels aux méthodes de callback qu'elle a enregistré l'état d'avancement de ses traitements. Par exemple, quand une application reçoit un événement correspondant à un élément titre , elle doit avoir mémorisé si l'événement parent était un élément personne (dans ce cas, le titre peut être Madame , Monsieur , ...) ou un élément livre . En outre, elle doit aussi avoir mémorisé quel était l'élément parent. Lors de la réception de l'événement correspondant à l'élément titre , elle doit recommencer.

Au contraire, dans le cas du parseur Pull, c'est l'application qui contrôle la communication. Et du fait du mode de communication, l'application peut gérer de manière implicite l'enchaînement des événements sans avoir à mémoriser l'état d'avancement de ses traitements. Ainsi, suivant l'exemple précédent, lors de la réception de l'événement correspondant à l'élément parent de titre , l'application va déterminer quel traitement doit être effectué. Ce traitement, spécifique selon qu'il s'agit d'un élément personne ou d'un élément livre , est chargé de traiter un éventuel événement titre . Ainsi, lors de la réception d'un élément titre , l'application n'a pas à déterminer quel traitement doit être effectué.

Un document XML n'est pas forcément statique. Il est, la plupart du temps, appelé à être modifié. En outre, ces modifications ne sont pas nécessairement toutes effectuées par un seul programme informatique, mais peuvent être réparties entre plusieurs programmes qui communiquent entre eux en utilisant des représentations internes du document XML. Par exemple, lors de la réception d'un document XML, un premier programme va être chargé de déchiffrer ce document (en supposant que le document est transmis de manière codée), puis un deuxième programme sera chargé de le traiter. À l'inverse, lors de l'envoi d'un document XML, un premier programme sera chargé de créer le document, tandis qu'un deuxième sera chargé de le chiffrer.

Dans le cas d'un parseur DOM, la modification du document XML s'effectue sur la représentation objet du document.

Dans le cas d'un parseur SAX ou Pull, la modification du document XML s'effectue en modifiant les événements transmis. Pour cela, au lieu d'avoir un parseur XML qui transmet des événements à l'application finale directement, les différents événements sont traités par une chaîne de filtres XML. Ainsi, chaque événernent géré par le parseur XML est transmis au premier filtre, qui le transmet au suivant et ainsi de suite jusqu'à l'application finale. À l'inverse, lors de la génération d'un document XML, l'application finale génère chaque événement et le transmet au dernier filtre, qui le transmet au précédent et de proche en proche jusqu'au générateur XML qui construit le document XML.

Bien évidemment, chaque filtre peut modifier tout événement, peut en supprimer ou en ajouter. Cependant le filtre doit avoir un comportement qui respecte le standard XML en transmettant un ensemble d'événements représentant un document XML correct. Ainsi, un filtre ne peut supprimer un événement correspondant à une balise de fermeture d'un élément, s'il n'a pas supprimé l'événement correspondant à la balise d'ouverture de ce même élément.

Les parseurs et les générateurs XML doivent gérer un certain nombre d'éléments lors de leurs traitements. Parmi ces éléments, ils doivent gérer les espaces de nommage (narnespace). Les espaces de nommage permettent de séparer les noms en plusieurs ensembles différents. Ils sont beaucoup utilisés en informatique pour différencier des noms identiques représentant des entités provenant de sources différentes. Comme XML permet de construire un nombre infini de langages basé sur sa syntaxe, il est vite apparu nécessaire de définir des espaces de nommage pour XML.

Dans XML, un espace de nommage est identifié par une adresse de type URI (Uniform Resource identifier). Ainsi l'URI http://www.crf.canon. fr/namespacel peut correspondre à un premier espace de nommage, tandis que l'URI http://www.crf.canon.fr/namespace2 peut correspondre à un deuxième espace de nommage. L'élément appelé exemple et situé dans le premier espace de nommage est différent de l'élément appelé lui aussi exemple mais situé dans le deuxième espace de nommage.

L'arbre des éléments, c'est-à-dire le véritable contenu du document XML, est constitué d'une hiérarchie de balises comportant éventuellement des attributs. Un attribut est une paire formée d'une clé et d'une valeur et écrite sous la forme Cle="Valeur", ainsi une balise affectée d'un attribut a la syntaxe suivante: <balise cle="valeur"> Toute donnée est ainsi encapsulée entre une balise ouvrante <balise> et une balise fermante </balise> (sachant qu'une donnée peut éventuellement être un ensemble d'éléments XML). En outre, un élément vide peut être uniquement constitué d'une balise spécifique dont la syntaxe est la suivante: <balise/>.

Ces notations n'intègrent pas l'espace de nommage auquel appartient l'élément. Comme les caractères autorisés pour un nom d'élément sont limités, il n'est pas possible de rajouter l'URI de l'espace de nommage directement au nom de l'élément. Aussi, à chaque espace de nommage utilisé dans un document, sont associés un ou plusieurs préfixes qui permettent de référencer cet espace de nommage.

Ainsi, on a par exemple: <nsl:exemple xmins:nsl="http://www.crf. canon.fr/namespacel">

</nsl:exemple>

L'attribut xmins: nsl="http://www.crf.canon.fr/namespacel" signifie que le préfixe nsl est associé à l'espace de nommage identifié par l'URI http://www.crf.canon.fr/namespacel.

2.5 L'utilisation de ce préfixe suivi de ':', dans le nom de l'élément... (à la fois dans la balise ouvrante et dans la balise fermante) signifie que cet élément se situe dans l'espace de nommage http://www.crf.canon.fr/namespacel.

La définition de ce préfixe s'applique à l'élément où elle se trouve et à tous les éléments qu'il contient: <nsl:exemple xmins:ns1="http://www.crf.canon.fr/namespacel"> <ns1:content>... </nsl:content>

</nsl:exemple>

L'élément content appartient lui aussi à l'espace de nommage http://www.crf.canon.fr/nannespacel.

Cette définition de préfixe peut être surchargée par une autre définition pour le même préfixe. Ainsi, dans l'exemple suivant: <nsl: exemple xmins:nsl ="http://vvww.crf.canon.fr/namespacel"> < nsl:other xmins:nsl ="http://www.crf.canon.fr/namespace2"> </ns l:other> <nsl:content> ... </ns 1:content> < /nsl:exemple> L'élément other appartient à l'espace de nommage http://www.crf.canon.fr/namespace2, tandis que l'élément content appartient à l'espace de stockage http://www.crf.canon.fr/namespacel.

Enfin, il est possible de définir un espace de nommage par défaut qui 15 s'applique à tous les éléments dont le nom n'est pas précédé par un préfixe.

<exemple xmins="http://vvww.crf.canon.fr/namespacel"> < /exemple> Dans cet exemple, l'élément exemple appartient à l'espace de nommage http://www.crf.canon.fr/namespacel.

II est à noter que l'ensemble de ces règles de définition des espaces de nommage s'applique non seulement aux éléments, mais aussi aux attributs, excepté en ce qui concerne la définition d'un espace de nommage par défaut: un attribut sans préfixe est dans un espace de nommage local à l'élément qui le contient.

Comme la plupart des langages XML utilisent les espaces de nommage, un parseur XML doit pouvoir les gérer. Ainsi, la grande majorité des parseurs XML existant est capable de gérer les espaces de nommage et peut, pour chaque élément ou attribut, indiquer à l'application l'espace de nommage dans lequel il se trouve.

À l'inverse, les générateurs XML sont capables de générer correctement le fragment XML décrivant un élément appartenant à un espace de nommage en définissant un préfixe pour cet espace de nommage et en précédant le nom de cet élément de ce préfixe. 10

Par contre, un problème spéclifique se pose dans le cas de parseur (ou générateur) SAX ou Pull avec une pile de filtres: comme chaque filtre modifie la structure du document XML, il peut être appelé à modifier les espaces de nornmage définis à un point donné du document. Chaque filtre doit 5 donc gérer correctement les espaces de nommage à son niveau.

Dans le cas d'un parseur ou générateur SAX ou Pull avec une pile de filtres, un problème nouveau apparaît: en effet, l'application peut à tout moment (c'est-à-dire à tout endroit du document qu'elle reçoit, donc après filtrage, ou qu'elle génère, donc avant filtrage) demander quel espace de nommage est associé à un préfixe ou quel préfixe est associé à un espace de nommage. Cette information est gérée par l'un des filtres ou par le parseur (ou générateur). Cependant, suivant le traitement effectué par chacun des filtres, cette information peut être conservée à tout endroit de la pile de filtres. Il est donc nécessaire de trouver une technique permettant de retrouver cette information.

D'autres problèmes similaires à la gestion des espaces de nommage peuvent se présenter. C'est le cas pour tout attribut décrivant une particularité de l'élément sur lequel il apparaît et des sous-éléments contenus par cet élément, cette description pouvant être surchargée par une nouvelle déclaration de l'attribut sur Sun sous-élément.

C'est; le cas, par exemple, de l'attribut xml:space qui décrit comment doivent être traités les espaces dans un document XML ou de l'attribut xml:lang qui décrit quelle langue est utilisée dans un document XML. Dans ces deux cas, l'application doit pouvoir obtenir la valeur de cet attribut à tout moment.

La présente invention apporte une solution à ces problèmes.

Elle porte sur un procédé de traitement d'un flot de données décrit dans un langage de balisage, comprenant au moins une balise, le traitement étant effectué par plusieurs filtres de traitement.

Selon une définition générale de l'invention, le procédé comprend les étapes suivantes lors du traitement d'une balise par un des filtres: i) extraction d'un mot clé et d'une valeur associée dans une balise, définissant au moins une caractéristique du flot de données; ii) vérification d'une condition de mémorisation; iii) si la vérification est positive, mémorisation localement du mot clé et de la valeur associée dans une ligne de correspondance d'une table, de façon à servir ladite valeur suite à une requête d'obtention de cette valeur.

Ainsi, la mémorisation d'une telle association mot clé - valeur permet de retrouver facilement l'un ou l'autre élément lors du traitement du flux de données, tant lors de la lecture que de la génération dudit flux de données.

Selon une réalisation, le procédé comprend en outre lors de l'étape iii) de mémorisation, une étape d'associiation d'un niveau de profondeur à la ligne de correspondance, le niveau de profondeur correspondant au degré d'imbrication de la balise dans le flot de données.

Selon une réalisation, le procédé comprend en outre les étapes suivantes: a) réception d'une requête demandant la valeur associée à un mot 15 clé ; b) recherche dudit mot clé et de la valeur associée dans la table; c) vérification d'une condition de réponse; d) si la vérification est positive, répondre à la requête avec la valeur associée.

Selon une autre réalisation, le procédé comprend l'étape suivante: di) si la vérification de la condition de réponse est négative, transmettre la requête à un autre filtre de traitement du procédé.

En pratique, la condition de réponse dépend de la profondeur de la ligne de correspondance de la table, du mot clé et de sa valeur associée et 25 d'une profondeur maximale indiquée dans la requête.

Selon encore une autre réalisation, le procédé comprend en outre une étape de mise à jour de la table comportant les étapes suivantes: 1) en réponse à une balise fermante à traiter, obtenir la dernière ligne de correspondance de la table, 2) obtenir le niveau de profondleur de la dernière ligne ainsi obtenue, 3) comparer le niveau de profondeur ainsi obtenu avec le niveau de profondeur de la ligne courante, 4) en cas niveau de profondeur supérieur ou égal au niveau de profondeur de la ligne courante, supprimer de la table le contenu de la dernière ligne.

Par exemple, le mot clé est un préfixe d'espace de nommage et la 5 valeur est le nom d'un espace de nommage.

Selon un autre exemple, le mot clé est le nom d'un espace de nommage et la valeur est un préfixe d'espace de nommage.

Selon une autre réalisation, la condition de mémorisation est la génération de la définition de l'espace de nommage par ledit filtre.

En pratique, le procédé de traitement de la balise est mis en oeuvre lors de la lecture du flot de données ou de la génération du flot de données.

La présente invention a également pour objet un dispositif de traitement d'un flot de données décrit dans un langage de balisage, comprenant au moins une balise ouvrante et une balise fermante, le traitement étant effectué par plusieurs filtres de traitement.

Selon une autre caractéristique, le dispositif comprend au niveau d'un filtre: - des moyens d'extraction d'un mot clé et d'une valeur associée dans une balise, définissant au moins une caractéristique de la balise; des moyens de vérification d'une condition de mémorisation; - des moyens de mémorisation aptes, si la vérification est positive, à mémoriser localement le mot clé et la valeur associée dans une ligne de correspondance d'une table, de façon à servir ladite valeur suite à une requête d'obtention de cette valeur.

Selon une réalisation, le dispositif de traitement comporte en outre des moyens d'association d'un niveau de profondeur à la ligne de correspondance, le niveau de profondeur correspondant au rang où l'association entre le mot clé et la valeur est réalisée.

Selon une autre réalisation, le dispositif de traitement comprend en 30 outre: - des moyens de réception d'une requête demandant la valeur associée à un mot clé ; - des moyens de recherche dudit mot clé et de la valeur associée dans la table; - des moyens de vérification d'une condition de réponse; et - des moyens d'envoi de réponse aptes, si la vérification est positive, à répondre à la requête avec la valeur associée.

La présente invention a encore pour objet un support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible., tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre du procédé de traitement visé ci-avant, lorsque ce programme est chargé et exécuté par un système informatique.

La présente invention a enfin pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre du procédé de traitement visé ci-avant, lorsque ce programme est chargé et exécuté par un système informatique.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure 1 décrit schématiquement un appareil programmable mettant en oeuvre le procédé selon l'invention; - la figure 2 décrit un exemple de mise en oeuvre de l'invention dans un ensemble de programmes traitant un document XML cette mise en oeuvre étant dans un dispositif de type parseur; - la figure 3 décrit l'opération inverse de celle décrite en référence à la figure 2, la mise en oeuvre de l'invention étant alors dans un dispositif de type générateur; - la figure 4A représente un document XML pouvant être lu dans le fichier de la figure 2 ou stocké dans le fichier de la figure 3; - la figure 4B représente le document de la figure 4A non chiffré ; - les figures 5A et 5B décrivent les tables servant à mémoriser les définitions des espaces de nommage et de préfixe au niveau du parseur ou du générateur selon l'invention; - la figure 6 décrit les opérations effectuées par un parseur ou un 5 filtre de parseur lorsqu'il obtient un événement correspondant à une balise ouvrante; - la figure 7 décrit les opérations effectuées par un parseur ou un filtre de parseur lorsqu'il obtient un événement correspondant à une balise fermante; - la figure 8 décrit les opérations effectuées par un générateur ou un filtre de génération quand il reçoit un événement; - la figure 9 décrit les opérations effectuées par un générateur ou un filtre de génération quand il reçoit un événement correspondant à la définition d'un préfixe pour un espace de nommage; et - la figure 10 décrit comment une application peut retrouver une association entre un préfixe et un espace de nommage.

Dans la description, le langage de balisage décrivant les flots de données est le langage XML. La syntaxe XML distingue un fragment qui est un morceau de XML, une balise qui est un morceau de XML commençant par '<' et se terminant par'>' et un élément qui est un morceau de XML commençant par une balise ouvrante et se terminant par une balise fermante correspondante (ou éventuellement une seule balise vide).

La présente invention n'est pas limitée au langage XML et à la syntaxe XML associée, mais s'applique à tout flot ou morceau de données 25 décrit en un langage de balisage.

En référence à la figure 1, on a décrit l'appareil programmable 101 mettant en oeuvre le procédé selon l'invention.

L'appareil comporte un bus de communication 209 auquel sont reliés: - une unité centrale de traitement 202 (microprocesseur), qui commande les échanges entre les divers éléments de l'appareil, - une mémoire morte 201 pouvant comporter les programmes, - une mémoire vive 205 cornportant des registres 208 adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes, - un disque dur 203 pouvant comporter les programmes précités, - un lecteur de disquette 211 adapté à recevoir une disquette 210 et à y lire ou à y écrire des documents traités ou à traiter selon l'invention, - une interface de communication 206 reliée à un réseau de communication 104, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des documents.

Le bus de communication 209 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil directement ou par l'intermédiaire d'un autre élément de l'appareil.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké par exemple dans le disque dur 203 ou en mémoire morte 201.

Selon une variante de réalisation, la disquette 210 peut contenir des documents ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil, est stocké dans le disque dur 203.

Selon une autre variante de réalisation, le code exécutable des programmes peut être reçu par l'intermédiaire d'un réseau de communication 104, via l'interface 206, pour être stocké de façon identique à celle décrite précédemment.

Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement: amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

De manière plus générale, le ou les programmes peuvent être chargés dans un des moyens de stockage de l'appareil avant d'être exécutés.

L'unité centrale 202 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 203 ou la mémoire morte 201 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 203 ou la mémoire ROM 201, sont transférés dans la mémoire vive RAM 205 qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

II convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé.

Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

En référence à la figure 2, le document XML est obtenu à partir d'un fichier 100. En variante, le document XML peut être obtenu à travers une connexion réseau ou tout autre type de moyen d'obtenir du texte. Le document XML est traité par un parseur XML 110 qui génère des événements représentant ce document et transmet ces événements, sur demande, aufiltre de déchiffrage 120, qui va transformer les éventuelles parties du document XML chiffrées en représentation en clair. Le filtre 120 transmet les événements résultant de son traitement à une application 130, qui peut à son tour effectuer le traitement qu'elle désire sur un document XML en clair.

En référence à la figure 3, on a décrit l'opération inverse de celle décrite à la figure 2. Une application 230 génère des événements représentant un document XML. Elle transmet ces événements à un filtre de chiffrage 220 qui chiffre les parties confidentielles du document. Le filtre 220 transmet les événements résultant à un générateur XML 210 qui va, pour chaque événement, générer un fragment XML correspondant à cet événement et stocker ce fragment généré dans un fichier 200.

Il est à noter que dans la suite de la description, sauf précision, tout ce qui s'applique aux événements de la figure 2 s'applique aussi aux 1 5 événements de la figure 3 avec inversion du sens de transmission des événements.

En référence à la figure 4A on a représenté un exemple de document XML pouvant être lu dans le fichier 100 de la figure 2 ou stocké dans le fichier 200 de la figure 3. Ce document comprend un élément externe doc et une partie représentant un contenu chiffré. Les éléments dans l'espace de nommage http:www.w3.org/2001/04/xmlenc# correspondent à des éléments définissant une partie chiffrée d'un message, le type de chiffrage utilisé... Le contenu de l'élément content correspond au contenu chiffré proprement dit.

En référence à la figure 4B on a représenté le document de la figure 4A non chiffré. Ce document correspond donc aux événements générés par le filtre 120 quand le parseur 110 traite le document de la figure 4A ou aux événements générés par l'application 230 et qui produiront le document de la figure 4A après son traitement par le filtre 220.

Il est à noter que dans le document de la figure 4A, existe un espace de nornmage http://www.w3.org/2001/04/xmlenc# qui n'existe pas dans celui de la figure 4B. À l'inverse, dans le document de la figure 4B, il existe un espace de nommage http://www.crf.canon.fr/namespace2 qui n'existe pas dans celui de la figure 4A.

Ainsi, si l'application 130 souhaite retrouver quel espace de nommage est associé au préfixe ns2 , elle peut obtenir l'information du filtre 120 qui associe ce préfixe à l'espace de nommage http://www. crf.canon.fr/namespace2 .

Par contre, si l'application 130 souhaite retrouver quel espace de nommage est associé au préfixe enc , elle ne peut pas obtenir l'information du filtre 120 qui ne voit que le document de la figure 4B dans lequel le préfixe enc n'est associé à aucun espace de nommage. Le document de la figure 4A, n'est vu que par le parseur 110 et le filtre 120. Ainsi, pour la même requête, le filtre 120 peut obtenir du parseur 110 que le préfixe enc est associé à l'espace de nommage http://www. w3.org/2001/04/xmlenc# .

Enfin, si l'application 130 souhaite retrouver quel espace de nommage est associé au préfixe nsl , elle peut demander cette information au filtre 120. Comme le filtre 120 n'exécute aucune modification sur l'élément doc du document de la figure 4A, le filtre 120 n'associe le préfixe nsl à aucun espace de nommage. Pour répondre à cette requête, le filtre 120 la transmet au parseur 110 qui associe le préfixe nsl à l'espace de nommage http://www.crf.canon. fr/namespacel .

Il est à noter que l'ensemble de ce fonctionnement est similaire dans le cas de la figure 3. Cependant, la requête généralement effectuée lors de la génération de document XML concerne le préfixe associé à un espace de nommage donné. En effet, l'application travaille sur les espaces de nommage et non sur les préfixes, mais peut, dans certains cas, avoir besoin de connaître le préfixe associé à un espace de nommage.

En référence à la figure 5A, on a décrit la table T servant à 15 mémoriser les définitions des espaces de nommage et de préfixe au niveau du parseur 110 (ou du générateur 210).

La première colonne CH1 correspond au préfixe, la deuxième colonne CH2 correspond au nom (l'URI) de l'espace de nommage et la troisième colonne CH3 correspond à la profondeur où cette association a été définie. Par construction, les lignes de ce tableau sont classées par ordre croissant de profondeur et de définition.

Par profondeur, on entend ici un degré d'imbrication de l'élément. Ainsi, l'élément racine a une profondeur de 1, ses sous-éléments directs une profondeur de 2 et ainsi de suite.

De part les règles de surcharge des définitions de préfixe, pour retrouver une association, ce tableau doit être parcouru depuis la fin.

La figure 5A représente l'état de la table quand le parseur (ou le générateur) traite le contenu de l'élément content .

En référence à la figure 5B, on a décrit la même table T, mais pour 30 le filtre 120 (ou le filtre 220). Elle représente l'état de la table quand le filtre de parseur (ou le filtre de générateur) traite le contenu de l'élément content .

En référence à la figure 6, on a décrit les opérations effectuées par un parseur (par exemple le parseur 110) ou un filtre de parseur (par exemple le filtre 120) quand il obtient un événement correspondant à une balise ouvrante (étape E500).

Le processus (étape E505) commence par augmenter la profondeur courante N de 1, puis (étape E510) il vérifie si l'événement a été généré par le filtre lui-même. Dans le cas d'un parseur, il s'agit de vérifier si l'événement provient du filtre en dessous ou s'il a été créé par le filtre lui-même (c'est le cas de l'événement correspondant à la balise ouvrante de l'élément msg de la figure 4B pour le filtre 120).

Dans le cas où l'événement n'a pas été généré par le filtre, le processus est terminé (étape E540). Dans le cas contraire, le processus va chercher si l'événement contient des déclarations de préfixe (étape E515). Si ce n'est pas le cas, le processus est terminé (étape E540). Si c'est le cas, il obtient chacune des déclarations (étapes E520 à E535) et les mémorise dans la table T avec la profondeur courante N (étape E525).

Ce processus permet ainsi de mémoriser dans la table T toutes les déclarations de préfixes pour un filtre donné. Le test E510 permet de ne mémoriser une déclaration qu'une seule fois dans l'ensemble de la pile.

En référence à la figure 7, on a décrit les opérations effectuées par un parseur (par exemple le parseur 110), un filtre de parseur (par exemple le filtre 120), un générateur (par exemple le générateur 210) ou un filtre de génération (par exemple le filtre 220) quand il obtient un événement correspondant à une balise fermante (étape E600).

Ce processus a pour rôle de supprimer de la mémoire T les déclarations de préfixe mémorisées lors du traitement de l'événement correspondant à la balise ouvrante de l'élément dont on traite la balise fermante.

Pour cela, le processus parcourt l'ensemble des lignes de la table T depuis la fin, pour obtenir la dernière ligne de la table T (étape E610) . On obtient ensuite la profondeur NL de la ligne (étape E620). Tant que la profondeur correspondant à la ligne NL est supérieure ou égale à la profondeur courante N (étape E630), la ligne est enlevée (étape E640). Dès que la profondeur NL de la ligne devient différente (donc inférieure) à la profondeur courante N (étape E630), la profondeur courante N est diminuée de 1 (étape E650) et le processus s'arrête (étape E660).

En référence à la figure 8, on a décrit les opérations effectuées par un générateur (par exemple le générateur 210) ou un filtre de génération (par exemple le filtre 220) quand il reçoit un événement (étape E700). Ce processus n'est effectué pour un filtre que dans le cas où il génère lui-même le fragment XML représentant l'événement reçu. C'est par exemple le cas pour le filtre 220 quand il reçoit les événements correspondant à l'élément msg , qu'il transforme en un fragment XML qu'il chiffrera ensuite avant de le transmettre au générateur 210.

Le processus commence par vérifier (étape E710) si l'événement correspond à la création d'une balise ouvrante.

Si c'est le cas, il vérifie si la précédente balise ouvrante était effectivement fermée (étape E715).

Si ce n'est pas le cas, il ferme la balise ouvrante précédente (étape E720). Pour cela, il parcourt l'ensemble des lignes de T et, si la profondeur correspondant à la ligne est égale à la profondeur courante N, il ajoute à la balise ouvrante une définition du préfixe de la ligne l'associant à l'espace de nommage de la ligne.

Dans les deux cas, il incrémente de 1 la profondeur courante (étape E725), puis met la variable balise à vrai (étape E730). Cette variable a pour rôle de mémoriser si la génération est à l'intérieur d'une balise ouvrante (elle permet en particulier de réaliser le test des étapes E715 et E735).

Dans le cas où le test de l'étape E710 est négatif, le processus vérifie si la précédente balise ouvrante doit être fermée (étape E735). Pour cela, il faut que la précédente balise ouvrante ne soit pas fermée (cette vérification utilise la variable balise ) et que l'événement ne soit pas l'ajout d'un attribut ou la définition d'un nouveau préfixe. En d'autres termes, on ferme une balise ouvrante quand le nouvel événement à générer ne complète pas la définition de la balise ouvrante (par exemple il s'agit d'une nouvelle balise, de contenu...).

Si le test de l'étape E735 est positif, le processus ferme la balise ouvrante courante (étape E740, identique à l'étape E720), puis mémorise faux 5 dans la variable balise .

Ensuite, le processus vérifie (étape E750) si l'événement correspond à une balise fermante. Si c'est le cas, il supprime (étape E755) les déclarations correspondant à la balise ouvrante associée en utilisant l'algorithme de la figure 7. Dans la négative, il met fin au procédé (étape E760).

En référence à la figure 9, on a décrit les opérations effectuées par un générateur (par exemple le générateur 210) ou un filtre de génération (par exemple le filtre 220) quand il reçoit un événement correspondant à la définition d'un préfixe pour un espace de nommage (étape E800).

Dans un premier temps (étape E805), le procédé vérifie si la définition de l'espace de nommage est créée au niveau du filtre, c'est-à- dire si la demande a pour origine le filtre de génération, ou l'application, juste au dessus du filtre auquel est appliqué le procédé ou si elle est seulement retransmise depuis un autre filtre ou l'application.

Ensuite, (étapes E810, E820, E830), le procédé calcule la profondeur correspondant à cette définition. Si le filtre est en cours de génération d'une balise ouvrante, c'est-à-dire si la variable balise a la valeur vraie (étape E820), cette profondeur est la profondeur courante, car la définition sera utilisée dans l'élément en cours de création. Sinon (étape E830), la définition sera valable pour le prochain élément à être créé : la profondeur associée est donc la profondeur courante majorée de 1.

Enfin (étape E840), le processus mémorise l'association dans le tableau T, avec la profondeur calculée, transmet cette définition d'un espace de nommage au filtre en dessous de lui, s'il existe, (étape E845), puis met fin au procédé (étape E850).

En référence à la figure 10, on a décrit comment une application peut retrouver une association entre un préfixe et un espace de nommage. Dans le cas d'une application recevant un document XML (par exemple 2C) l'application 130), l'application souhaite généralement connaître l'espace de nommage associé à un préfixe. Dans le cas d'une application créant un document XML (par exemple l'application 230), l'application souhaite généralement connaître le préfixe associé à un espace de nommage.

Ce processus traite ces deux cas de la même manière. Il est mis en oeuvre soit dans un parseur (exemple: 110), soit dans un filtre de parseur (exemple: 120), soit dans un générateur (exemple: 210), soit dans un filtre de générateur (exemple: 220).

Lors d'une requête pour obtenir une association entre un préfixe et un espace de nommage (étape E900), une profondeur maximale de recherche est transmise (Nmax). Si cette profondeur n'est pas transmise (c'est le cas lorsque la requête est émise directement par une application), elle est considérée comme ayant la profondeur courante du filtre (ou parseur, ou générateur) la recevant.

Le processus obtient en premier lieu la dernière ligne de T (étape E905). Puis il obtient la profondeur associée à cette ligne, NL (étape E910).

Un test (étape E915) est réalisé sur la valeur NL. Si NI est supérieure à Nmax, le processus ne doit rien effectuer: l'association mémorisée dans cette ligne est contenue dans un élément qui est modifié par un filtre plus haut placé et n'est donc pas visible par la source originelle de la requête.

Dans le cas contraire, le processus vérifie si la ligne correspond à la requête (étape E920). C'est-à-dire que si la requête correspond à l'obtention d'un espace de nommage associé à un préfixe, le processus vérifie si le préfixe passé en paramètre est identique au préfixe mémorisé dans la ligne. Si c'est le cas, la réponse est l'espace de nommage mémorisé dans la ligne. Pour une requête d'association inverse, la réponse est le préfixe. Si la ligne correspond à la requête, le processus retourne la réponse (étape E925).

Si le test de l'étape E915 ou E920 est négatif, le processus vérifie si une ligne précédente existe (épate E930) et si oui reprend le traitement avec 30 cette ligne précédente (étape E935).

Sinon, le processus vérifie si un filtre existe en dessous (étape E940). Si ce n'est pas le cas, il retourne un échec (étape E945).

Si c'est le cas, il transmet la requête au filtre du dessous (étape E950). La profondeur maximum de recherche pour le filtre du dessous est la valeur minimale entre la profondeur maximale Nmax transmise au processus et la profondeur Nfiltre à partir de laquelle le filtre courant a modifié les éléments 5 XML qu'il recevait, modifiant par là même les associations correspondantes.

Enfin, le processus retourne le résultat de la requête ainsi transmise (étape E955).

Claims (20)

REVENDICATIONS

1. Procédé de traitement d'un flot de données décrit dans un langage de balisage, comprenant au moins une balise, le traitement étant effectué par plusieurs filtres de traitement, caractérisé en ce qu'il comprend les étapes suivantes lors du traitement d'une balise par un des filtres: i) extraction d'un mot clé et d'une valeur associée, définissant au moins une caractéristique du flot de données; ii) vérification d'une condition de mémorisation; iii) si la vérification est positive, mémorisation localement du mot clé et de la valeur associée dans une ligne de correspondance d'une table (T), de façon à servir ladite valeur suite à une requête d'obtention de cette valeur.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre lors de l'étape iii) de mémorisation, une étape d'association d'un niveau de profondeur à la ligne de correspondance, le niveau de profondeur correspondant au degré d'imbrication de la balise dans le flot de données.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend en outre les étapes suivantes a) réception d'une requête demandant la valeur associée à un mot clé ; b) recherche de ce mot clé et de la valeur associée dans la table (T) ; c) vérification d'une condition de réponse; d) si la vérification est positive, répondre à la requête avec la valeur associée.

4. Procédé selon la revendication 3, caractérisé en ce qu'il comprend les étapes suivantes: di) si la vérification de la condition de réponse est négative, transmettre la requête à un autre filtre de traitement du procédé.

5. Procédé selon l'une des revendications 3 à 4, caractérisé en ce que la condition de réponse dépend de la profondeur de la ligne de correspondance de la table (T), du mot clé et de sa valeur associée et d'une profondeur maximale indiquée dans la requête.

6. Procédé selon l'une des revendications 2 à 5, caractérisé en ce 10 qu'il comprend en outre une étape de mise à jour de la table (T) comportant les étapes suivantes: 1) en réponse à une balise fermante à traiter, obtenir la dernière ligne de correspondance de la table (T), 2) obtenir le niveau de profondeur de la dernière ligne ainsi obtenue, 15 3) comparer le niveau de profondeur ainsi obtenu avec le niveau de profondeur de la ligne courante, 4) en cas niveau de profondeur supérieur ou égal au niveau de profondeur de la ligne courante, supprimer de la table le contenu de la dernière ligne.

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que le mot clé est un préfixe d'espace de nommage et la valeur est le nom d'un espace de nommage.

8. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que le mot clé est le nom d'un espace de nommage et la valeur est un préfixe d'espace de nommage.

9. Procédé selon la revendication 7 ou 8, caractérisé en ce que la 30 condition de mémorisation est la génération de la définition de l'espace de nommage par ledit filtre.

10. Procédé selon les revendications 7 et 9, caractérisé en ce que le procédé est mis en oeuvre lors de la lecture du flot de données.

11. Procédé selon les revendications 8 et 9, caractérisé en ce que le procédé est mis en oeuvre lors de la génération du flot de données.

12. Dispositif de traitement d'un flot de données décrit dans un langage de balisage, comprenant au moins une balise, une balise comportant au moins une balise ouvrante et une balise fermante, le traitement étant effectué par plusieurs filtres de traitement, caractérisé en ce qu'il comprend au niveau d'un filtre: - des moyens d'extraction d'uni mot clé et d'une valeur associée dans une balise, définissant au moins une caractéristique de la balise; - des moyens de vérification d'une condition de mémorisation; - des moyens de mémorisation aptes, si la vérification est positive, à mémoriser localement le mot clé et la valeur associée dans une ligne de correspondance d'une table (T), de façon à servir ladite valeur suite à une requête d'obtention de cette valeur.

13. Dispositif selon la revendication 12, caractérisé en ce qu'il comporte en outre des moyens d'association d'un niveau de profondeur à la ligne de correspondance, le niveau de 1profondeur correspondant au rang où l'association entre le mot clé et la valeur est définie.

14. Dispositif selon la revendication 12 ou 13, caractérisé en ce qu'il comprend en outre: - des moyens de réception d'une requête demandant la valeur associée à un mot clé ; - des moyens de recherche dudit mot clé et de la valeur associée

dans la table (T) ;

- des moyens de vérification d'une condition de réponse; - des moyens d'envoi de réponse aptes, si la vérification est positive, à répondre à la requête avec la valeur associée.

15. Dispositif selon l'une des revendications 12 à 14, caractérisé en 5 ce qu'il comporte des moyens aptes à mettre en ouvre le procédé de traitement selon l'une des revendications 4 à 9.

16. Dispositif selon l'une des revendications 12 à 15, caractérisé en ce qu'il est inclus dans un filtre de traitement.

17. Dispositif selon l'une des revendications 12 à 16, caractérisé en ce qu'il fait partie d'un système de type parseur, apte à lire le flot de données.

18. Dispositif selon l'une des revendications 12 à 16, caractérisé en 15 ce qu'il fait partie d'un système de type générateur, apte à générer le flot de données.

19. Support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.

20. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.