FR2927712A1 - Procede et dispositif d'acces a une production d'une grammaire pour le traitement d'un document de donnees hierarchisees. - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif d'accès à une production d'une grammaire pour le traitement d'un document (1) de données d'un document structuré, par exemple XML.Le procédé concerne l'accès à une production parmi une pluralité de productions d'au moins une grammaire, où des productions sont associées à un premier groupe d'événements décrivant les données et définis par un type d'événement et une information contextuelle, le procédé comportant :a) une étape consistant à déterminer (210) si un événement considéré est du premier groupe;b) dans l'affirmative, une étape de prédiction (230, 410, 510) d'une production associée audit événement considéré.Pour des événements notamment dépourvus d'information contextuelle, on détermine (220) la production de l'événement à l'aide d'un numéro d'événement, par exemple en utilisant le modèle StAX.La prédiction (230) est effectuée à l'aide de transitions mémorisées entre les événements.

Description

1 La présente invention concerne un procédé et un dispositif de traitement de documents structurés. Elle s'applique, en particulier, au langage XML (acronyme de Extensible Markup Language pour langage de balisage extensible). Ce langage est une syntaxe pour définir des langages informatiques. XML permet ainsi de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et se terminant par une balise fermante comportant, elle aussi, le nom de l'élément (par exemple: </balise>). Chaque élément peut contenir d'autres éléments de façon hiérarchique ou des données textuelles. D'autre part, un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple : <balise attribut="valeur">).

La syntaxe XML permet aussi de définir des commentaires (par exemple: <!-- Commentaire-->) et des instructions de traitement, qui peuvent préciser à une application informatique les traitements à appliquer au document XML (par exemple : <?montraitement?> ), ainsi que des sections d'échappement qui permettent d'éviter qu'une section de texte soit interprétée comme une balise lorsqu'elle en a la forme (par exemple : <![CDATA[<texte>Echappement</texte>]]> où <texte> est reconnu comme une chaîne de caractère et non pas une balise). Dans la terminologie XML, l'ensemble des termes élément , attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement sont regroupés sous le nom générique de item . Dans un cadre plus général, l'ensemble de ces termes (formant par 2

exemple l'élément défini entre une balise ouvrante et une balise fermante) peut être regroupé sous le nom générique de noeud . Ces données XML peuvent être décrites en termes d'événements. Ainsi, à chaque partie d'un document correspondra un événement. Pour un élément <balise></balise>, on distingue d'abord un événement Début d'élément , cet événement étant caractérisé par le nom balise , puis un événement Fin d'élément qui, selon la topologie des langages de balisage, contient un rappel au nom d'élément correspondant, ici /balise , mais n'en apparaît pas moins indépendant car un élément Fin d'élément met conventionnellement fin à l'élément dernièrement ouvert. Les autres événements les plus fréquents sont les événements Caractères pour les données textuelles, Commentaire pour les commentaires, ou encore Attribut pour les attributs. Plusieurs langages différents basés sur le XML peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace selon la terminologie anglo-saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier , pour Identifiant uniforme de ressource), par exemple http://canon.crf.fr/xml/monlangage . L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: xmins:ml="http://canon.crf.fr/xml/monlangage" associe le préfixe ml à l'URI http://canon.crf.fr/xml/monlangage ). Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de : (par exemple: <ml:balise ml:attribut="valeur"> indique que l'élément balise découle de l'espace de nommage ml et qu'il en est de même pour l'attribut attribut). 3

Dans certains cas, les éléments ou données XML ci-dessus sont traités informatiquement à l'aide d'une description de langage approprié, appelée grammaire. Cette description repose sur différentes règles, aussi appelées productions, et en combinant ces productions l'on peut, au choix, vérifier que des données sont conformes à cette grammaire, ou bien générer des données conformes à cette grammaire, par exemple pour encoder ces données. A titre illustratif uniquement, on prend l'exemple suivant composé d'un alphabet de deux symboles, A et B, d'un symbole X comme symbole de départ et de deux productions : PO:X -AX Pl:X -B En partant de X, on obtient AX en utilisant la production P0. Si l'on applique à nouveau la production P0, on obtient AAX. On applique alors la production P1, et l'on obtient AAB. Le langage généré par cette grammaire est l'ensemble des chaînes constituées d'un certain nombre de A puis d'un B. Ainsi, productions et grammaires constituent un ensemble de règles de construction d'un document de données hiérarchisées, ici un fichier XML. L'utilisation de grammaires est intéressante pour certaines opérations effectuées sur des données XML, dont on fournit deux exemples ci-après. Le premier exemple vise la validation de données XML. Selon cette dernière, on vérifie que le contenu d'un document XML correspond à un modèle. Ce modèle est décrit dans ce qu'on l'on nomme un schéma. Ainsi, selon un exemple, un schéma peut définir un élément livre en spécifiant qu'un livre contient une référence, un titre, un auteur et une date de parution ; d'autre part, l'élément auteur peut être défini comme contenant un nom, un prénom et une date de naissance. Un schéma étant connu, il est donc possible d'évaluer la conformité d'un document XML par rapport à ce schéma. Une méthode classique pour procéder à cette évaluation est basée sur l'utilisation de grammaires : à partir du schéma, on construit des grammaires, chaque grammaire contenant les 4

productions correspondant aux événements possibles selon le schéma. Si aucun ordre n'est spécifié entre la référence, le titre, l'auteur et la date de parution, le contenu d'un élément livre est décrit par une grammaire contenant une production pour chacun de ces éléments (en cas de contrainte, notamment de contrainte d'ordre, il y a lieu de prévoir une grammaire plus complexe qui n'autorise que les séquences correspondant à ces contraintes). Si l'on rencontre des données qui ne correspondent à aucune de ces productions, alors les données ne sont pas conformes et la validation échoue. Le deuxième exemple est celui de la compression de données XML.

Les données XML sont des données textuelles généralement redondantes, aussi est-il utile de les compresser. La méthode la plus classique pour compresser des données XML consiste à remplacer les balises XML par des codes. Ainsi, on peut décider que pour un début d'élément livre, on utilise le code hexadécimal 0x01, tandis que pour un début d'élément auteur on utilise 0x02, et le code OxFF désigne quant à lui la fin d'un élément. Toutefois, avec ce type d'encodage, la compression n'est pas optimale car quel que soit le contexte courant, un code a toujours le même sens. Or, selon le contexte, seuls certains événements peuvent se produire. Prenons l'exemple de l'élément livre et de l'élément auteur : si le document XML présente une liste de livres, alors il est logique que l'élément auteur n'apparaisse qu'à l'intérieur d'un élément livre, l'auteur étant vu dans ce cas comme une caractéristique du livre. Par conséquent, on peut considérer qu'il n'est pas utile de réserver le code 0x02 pour auteur quand on ne se trouve pas dans un livre, car on a supposé que dans ce contexte l'élément auteur ne se produirait pas.

Une solution pour améliorer cette technique repose sur l'utilisation des grammaires présentées ci-dessus. C'est notamment le cas d' Efficient XML , format utilisé comme base pour la standardisation d'un format XML binaire par le groupe de travail EXI (acronyme de "Efficient XML Interchange") du W3C (acronyme de World Wide Web Consortium , organisation produisant des standards pour le Web), qui prend en compte l'ordre d'apparition des différents items au sein d'un document pour construire une grammaire qui permet d'encoder les items les plus fréquents sur un faible nombre de bits. A chaque élément, on associe une grammaire qui décrit les données susceptibles d'être rencontrées à l'intérieur de cet élément. Pour chaque type de donnée, c'est-à-dire pour chaque type d'événement à l'intérieur de ce contexte élément, une production est insérée dans la grammaire et un code est associé à cette 5 production. De cette manière, les codes utilisés pour coder les données dépendent du contexte, ce qui permet d'utiliser des codes de taille moindre. Dans le cas du livre et de l'auteur, la grammaire associée à l'élément livre comporte une production décrivant le début de l'élément auteur, et les autres grammaires ne comportent alors pas une telle production.

Lorsque l'on traite des données ainsi structurées en utilisant des grammaires, il est connu de façon conventionnelle de rechercher la production décrivant une donnée, correspondant à un événement dans le contexte élément, en utilisant une table de hachage. Cette table associe des clefs, correspondant aux données, à des objets, correspondants aux productions.

Ainsi, à partir d'une donnée dans l'élément, on calcule un nombre en utilisant une fonction de hachage. La production décrivant ladite donnée se trouve alors dans la table à l'index correspondant au nombre obtenu. Les temps d'accès à une table de hachage sont en moyenne satisfaisants. Néanmoins, le défaut d'une telle solution réside dans le calcul coûteux, en temps et en ressources, de la valeur de hachage à l'aide d'une fonction de hachage. Des solutions alternatives ont été proposées pour accéder aux productions décrivant les données dans un élément. On connaît notamment des grammaires probabilistes dans lesquelles on associe à chaque production une probabilité et à partir desquelles on détermine la production qui a le plus de chances d'être utilisée. Ces grammaires probabilistes présentent cependant l'inconvénient de requérir un apprentissage à l'aide d'un certain nombre de documents structurés antérieurs, comme illustré par la demande de brevet US 2007 / 0 022 373. Cet apprentissage engendre également des coûts importants antérieurement au traitement d'un document structuré et ne permet pas le traitement efficace de documents de provenances différentes, en particulier si le 6

document à traiter ne présente pas une structure proche de celles des documents d'apprentissage. Ainsi, il se pose le problème de savoir comment obtenir plus efficacement une production pour un événement à traiter.

L'invention vise à remédier aux inconvénients mentionnés ci-dessus en proposant un traitement des données hiérarchisées mettant en oeuvre une distinction entre au moins deux ensembles d'événements à traiter, par exemple ceux qui présentent des propriétés contextuelles et ceux qui n'en présentent pas, et en effectuant une prédiction pour un ensemble d'événements ayant une nature contextuelle. A cet effet, l'invention vise notamment un procédé d'accès à une production parmi une pluralité de productions d'au moins une grammaire, ladite pluralité de productions comprenant un premier groupe de productions associées à un premier groupe d'événements définis chacun par un type d'événement et une information contextuelle, et un deuxième groupe de productions associées à un deuxième groupe d'événements distinct du premier groupe, lesdits événements décrivant des données hiérarchisées d'un document électronique structuré, ledit procédé comportant : a) une étape consistant à déterminer si un événement considéré est 20 du premier groupe ; b) dans l'affirmative, une étape de prédiction d'une production associée audit événement considéré. Une fois la production obtenue, il est aisé de mettre en place un traitement spécifique comme indiqué précédemment. 25 Ainsi en différentiant au moins deux groupes d'événements et de productions en fonction notamment de la présence ou non d'une information complémentaire contextuelle (qui généralement se présente sous la forme d'une propriété d'un type d'événement), on peut appliquer une recherche ciblée, avec par exemple une recherche simplifiée pour des événements généraux de 30 l'ensemble des données hiérarchisées et une recherche adaptée avec prédiction pour les événements fortement dépendants du contexte dans lequel ils s'inscrivent. En cas de prédiction, on évite alors le calcul de valeurs de 7

hachage de l'art antérieur. En faisant ainsi des économies en calcul, on accède globalement à moindre coût et plus rapidement aux productions souhaitées. Le procédé s'applique à tout type de document électronique structuré, notamment des fichiers numériques, par exemple de type XML.

L'appartenance d'un événement à un groupe spécifique permet de définir le traitement à appliquer à l'événement considéré en fonction, le cas échéant, de l'information contextuelle à laquelle il se rattache. Les événements du premier groupe présentent une information contextuelle en sus d'un type d'événement. Ainsi, à type d'événement identique, par exemple le type d'événement 'début d'élément', deux événements de ce groupe peuvent différer lorsque l'on considère, entre autres, le nom de l'élément auquel ils se rapportent. Ce nom permet notamment d'indiquer les grammaires et productions liées. Ces événements associés à des productions dites "qualifiées", ici le premier groupe de productions, comme on le verra par la suite, contiennent ainsi au moins une information contextuelle qui est une propriété de l'événement autre que son type. A l'inverse, les événements du second groupe ont des fonctions génériques pour tout ou partie du document, correspondant à une grammaire. Ce peut être le cas par exemple d'événements basés sur le type d'événement de type caractère ou fin d'élément' Du fait de cette généricité, les productions correspondantes ne tiennent pas compte des propriétés éventuellement précisées dans ces événements, de telle sorte que ces événements sont assimilés à leur simple fonction, c'est-à-dire généralement le type d'événement uniquement. Ces événements sont décrits par des productions dites "simples", ici le deuxième groupe de production, comme on le verra par la suite. En particulier, ladite information contextuelle peut comporter, dans ledit événement, un nom associé à un élément des données hiérarchisées, par exemple soit directement le nom de l'élément (en incluant éventuellement l'espace de nommage) soit le nom d'un attribut applicable à cet élément (en incluant également l'espace de nommage le cas échéant), de telle sorte que la production associée audit événement est définie dans ou est fonction du contexte dudit élément.

Cette disposition inclut également le cas des événements textuels qui peuvent prendre un nombre limité de valeurs distinctes, en particulier deux valeurs distinctes. L'information contextuelle est, dans ce cas, la valeur prise par l'événement considéré, une production spécifique associée ayant été prévue pour chacune des valeurs possibles. A contrario, on note qu'un événement non lié à un élément de telle sorte que sa production descriptive n'est pas fonction dudit élément, n'entre pas dans le cadre des événements présentant une telle information contextuelle, c'est le cas notamment des balises de fin d'élément.

Par la suite, on appelle nom qualifié un nom d'élément ou d'attribut qui définit ainsi une information contextuelle, ceci afin d'éviter des ambiguïtés entre différents usages du mot nom . Comme indiqué ci-dessus, si la prédiction est exacte, le traitement de l'événement considéré est effectué conformément à la production prédite.

A ce titre, on envisage que le procédé comprend une étape de vérification de ladite prédiction, ladite vérification pouvant consister en une comparaison entre l'événement considéré et l'événement décrit par la production prédite, notamment entre le nom qualifié dudit événement considéré et le nom qualifié de ladite production prédite.

Ainsi, en cas de vérification négative, on prévoit une étape de détermination d'une production à l'aide d'une table de hachage, ce qui correspond aux mécanismes classiques. Grâce à cette disposition, on s'assure que le traitement d'un événement selon l'invention n'est au pire (donc en cas d'échec de la prédiction) que faiblement plus coûteux que celui de l'art antérieur à l'aide de tables de hachage. En outre, dans ce cas, on prévoit une mise à jour d'informations de prédiction, afin d'améliorer la prédiction future pour le reste du document. Ces informations seront précisées dans la suite de la description. On prévoit également que cette étape de mise à jour puisse avoir lui-même en l'absence d'erreur dans la prédiction. C'est notamment le cas lorsque l'on tient compte du ratio entre les prédictions et les prédictions erronées pour effectuer cette mise à jour. 9

Dans un mode de réalisation, en cas de détermination négative à l'étape a) (cas d'un événement du deuxième groupe décrit par une production simple), le procédé comprend la détermination d'une production associée à l'événement considéré et comprenant le calcul d'une donnée d'identification dudit événement considéré et la récupération d'une production dans une table à partir de ladite donnée d'identification. En particulier, si l'on utilise le modèle de traitement XML StAX (interface de programmation XML en flux continu ou "Streaming API for XML" selon la terminologie anglo-saxonne), la donnée d'identification de l'événement considéré pourra correspondre à la valeur du numéro de cet événement dans le modèle StAX. A titre d'exemple, le numéro StAX de l'événement 'caractère' est 4. Egalement, les productions du deuxième groupe (c'est-à-dire dépourvus de contexte) sont mémorisées dans un tableau, chacune à l'index correspondant à ladite donnée d'identification, notamment la valeur StAX de l'événement associé. On rappelle ici qu'en présence de plusieurs grammaires, on peut décliner un tableau regroupant les productions simples pour chacune des grammaires. L'invention a également trait à un procédé de traitement d'un document électronique comprenant des données hiérarchisées organisées en une pluralité d'items ou d'éléments pouvant êtres décrits par un ensemble d'événements en utilisant au moins une grammaire comportant des productions, ledit procédé comportant : i) une étape d'extraction d'un événement à traiter ; ii) une étape d'accès à une production associée audit événement à traiter conformément au procédé d'accès ci-dessus.

A titre illustratif, l'extraction peut être réalisée de façon conventionnelle à l'aide d'un analyseur syntaxique (parseur selon un anglicisme répandu ou "parsec" selon la terminologie anglo-saxonne), par exemple XML dans le cas d'un document de même format. En particulier, on réitère les étapes i) et ii) pour une pluralité 30 d'événements dudit document. Dans un mode de réalisation, la grammaire comprend au moins une transition associant, notamment de façon unidirectionnelle, une production dite 10

"précédente" à une production dite "suivante", ladite prédiction à l'étape b) comprenant la détermination d'une production suivante associée à une production décrivant un événement traité lors d'une itération précédente. L'utilisation de transitions offre une représentation peu coûteuse de l'enchaînement des événements type XML dans un document. L'accès à une production et le traitement de l'événement correspondant sont alors rendus plus efficaces. En particulier, les événements dudit document sont regroupés en différents types, ladite prédiction d'un événement d'un type étant effectuée à partir de la production associée au dernier événement de même type traité. On distingue notamment les événements de type attributs, les événements de type début d'élément et éventuellement les événements textuels prenant une valeur parmi un nombre limité de valeurs distinctes. Grâce à ces dispositions, on assure une prédiction plus efficace car les enchaînements sur des événements de même type sont généralement plus homogènes et redondants qu'entre événements de type distinct. En alternative, on peut prévoir de prendre le dernier événement traité lors de l'itération précédente, sans tenir compte du type d'événement. Selon deux réalisations envisagées, ladite transition est mémorisée dans une structure de la production précédente ou ladite transition est mémorisée dans une table de transitions, auquel cas on dispose d'autant de tables que de types d'événements lorsqu'une prédiction typée est réalisée. Dans un mode de réalisation se rapportant à la mise à jour d'informations de prédiction comme introduite ci-dessus, on peut prévoir que ladite mise à jour comprend la mémorisation d'une transition entre la production associée à l'événement précédemment traité et la production déterminée à l'aide de la table de hachage. Grâce à ces dispositions, en cas de redondance limitée dans le document type XML, on fait évoluer les critères de prédiction et donc l'efficacité de cette dernière. On accède ainsi plus rapidement aux productions. Notamment, la mise à jour peut comprendre la substitution d'une transition déjà existante par ladite transition à mémoriser, ces deux transitions étant effectivement concurrentes en ce qu'elles présentent une même 11

production précédente égale à la production associée à l'événement antérieurement traité. En général, on procède à cette mise à jour de façon systématique dès qu'une prédiction n'est pas correcte.

Cependant, on envisage que ladite mémorisation de la transition dépend d'au moins un paramètre prédéfini. Notamment, un paramètre prédéfini peut être un ratio et une valeur seuil correspondante du nombre d'occurrences, dans le document type XML, entre la transition et une transition concurrente, c'est-à-dire une transition partant d'une même production précédente vers une production suivante différente. En alternative, on peut prévoir que la transition est mémorisée de façon définitive et ne peut être substituée par une transition concurrente alternative. Dans un mode de réalisation, le procédé comprend une étape d'inactivation d'une transition, ci-après nommée 'transition opaque'. Cette propriété permet de tenir compte, par exemple, d'un trop grand nombre de prédictions erronées. Cette transition peut éventuellement être substituée par la suite. En particulier, l'étape d'inactivation dépend d'au moins un paramètre prédéfini. Notamment, un paramètre prédéfini peut être un ratio et une valeur seuil correspondante, entre le nombre de prédictions réalisées à partir de la production précédente et le nombre d'échecs rencontrés. On peut envisager également de tenir compte de ce ratio uniquement lorsque le nombre de prédictions atteint une valeur seuil. En alternative au ratio, on peut tenir compte uniquement du nombre d'échecs et d'un seuil à partir duquel la transition est rendue inactive. Dans un mode de réalisation dans lequel on vérifie la prédiction, on prévoit que : a) en cas de vérification négative, on détermine si la production associée à l'événement précédemment traité peut se répéter, et R) en cas de détermination positive à l'étape a), on compare l'événement associé à la production précédemment traitée avec l'événement extrait. 12 Ainsi, en cas de comparaison négative à l'étape R), on détermine une production associée à l'événement extrait à partir d'une table de hachage, et on met éventuellement à jour des informations de prédiction. En cas de comparaison positive à l'étape R), on dispose déjà de la production associée à l'événement à traiter. Par ailleurs, on prévoit qu'en cas de détermination négative à l'étape a), on détermine une production associée à l'événement extrait à partir d'une table de hachage, on compare la production associée à l'événement précédemment traité et la production obtenue à partir de la table de hachage et on met à jour un indicateur de répétition, type drapeau, dans ladite production en cas de comparaison positive. Cet indicateur sert ainsi dans l'étape consistant à déterminer si une production peut se répéter, par simple lecture. Dans un mode de réalisation, lesdites grammaire et productions sont formées au fur et à mesure du traitement des données dudit document. Ainsi, on procure un procédé dynamique qui s'adapte à chaque nouveau document à traiter, sans nécessiter d'apprentissage préalable. L'invention a également trait à un dispositif d'accès à une production parmi une pluralité de productions d'au moins une grammaire, ladite pluralité de productions comprenant un premier groupe de productions associées à un premier groupe d'événements définis chacun par un type d'événement et une information contextuelle, et un deuxième groupe de productions associées à un deuxième groupe d'événements distinct du premier groupe, lesdits événements décrivant des données hiérarchisées d'un document électronique structuré, ledit dispositif comportant : - un premier moyen de détermination apte à déterminer si un événement considéré est du premier groupe ; - un moyen de prédiction apte à prédire une production associée à un événement du premier groupe. Selon un mode de réalisation, ledit moyen de prédiction comprend des transitions associant une production dite "précédente" à une production dite "suivante", le moyen de prédiction étant apte à déterminer la production 13

suivante associée à une production décrivant un événement traité précédemment. En particulier, le moyen de prédiction comprend au moins une table référençant lesdites transitions.

En variante, au moins une production référence une production suivante de sorte à former implicitement une desdites transitions. Dans un mode de réalisation, le dispositif comprend un moyen de vérification des prédictions dudit moyen de prédiction et un deuxième moyen de détermination d'une production apte à déterminer une production à partir d'une table de hachage lorsque la prédiction est erronée. Selon une autre caractéristique particulière de l'invention, le dispositif comprend un troisième moyen de détermination d'une production associée à un événement du deuxième groupe, ledit troisième moyen de détermination comprenant une table associant, à une donnée d'identification d'un événement, une production décrivant ledit événement. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques des procédés d'accès et de traitement exposés précédemment. L'invention concerne également un dispositif de traitement d'un document électronique comprenant des données hiérarchisées organisées en une pluralité d'items ou d'éléments pouvant êtres décrits par un ensemble d'événements en utilisant au moins une grammaire comportant des productions, ledit dispositif comportant : - un moyen d'extraction d'un événement à traiter ; - un dispositif d'accès à une production associée audit événement à traiter comme introduit ci-dessus. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de traitement exposé précédemment.

Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le 14

procédé d'accès ou de traitement conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. Un programme d'ordinateur lisible par un microprocesseur, comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé d'accès ou de traitement conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre.

D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 illustre des grammaires et structures pour la mise en oeuvre d'un exemple de réalisation de l'invention ; - la figure 2 montre une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre du procédé selon l'invention ; - la figure 3 représente, sous forme d'un logigramme, un exemple de traitement de données selon l'invention ; - la figure 4 représente, sous forme d'un logigramme, des étapes d'obtention d'une production mise en oeuvre dans le processus de la figure 3 ; - la figure 5 représente, sous forme d'un logigramme, des étapes d'obtention d'une production sans prédiction mise en oeuvre dans le processus de la figure 4 ; - la figure 6 représente, sous forme d'un logigramme, des étapes d'obtention d'une production par prédiction mise en oeuvre dans le processus de la figure 4 ; et - la figure 7a et 7b représentent, sous forme de logigrammes, des étapes de traitement des prédictions mises en oeuvre dans le processus de la figure 6. 15

On illustre tout d'abord l'invention par un exemple de réalisation à partir de grammaires et structures mises en oeuvre, comme représentées par la figure 1. Cet exemple est décrit à partir du document XML 1 décrivant une personne à l'aide d'un prénom et d'un nom.

Cette figure 1 donne un exemple de grammaire et de structures associées, ces structures étant utilisées par l'invention. Le tableau 010 présente une grammaire contenant des productions décrivant les événements suivants : début d'élément person, début d'élément firstName, début d'élément lastName, caractères (contenu textuel) et fin d'élément. La construction de cette grammaire ne relève pas de l'invention. Il convient de noter que cette grammaire décrit à elle seule toutes les données, ceci dans le but de simplifier l'exemple, mais il est souvent intéressant de procéder différemment et d'associer, par exemple, une grammaire propre à chaque élément (en l'occurrence, une grammaire pour person, une pour firstName et une pour lastName). De cette manière, on sépare les informations, ce qui est généralement avantageux puisque, ainsi, chaque grammaire définit uniquement les événements qui ont réellement une chance de se produire. Si l'on considère la grammaire de l'exemple, on pourrait avoir un début d'élément person à l'intérieur d'un élément firstName, or ceci ne se produit pas pour les données de l'exemple (c'est l'élément person qui contient l'élément firstName, et le contraire n'aurait pas de sens). Dans l'exemple du document 1 de la figure 1, les productions StartElement person, StartElement firstName et StartElement lastName sont associées à un nom, tandis que les productions Characters et EndElement ne le sont pas. On distingue ainsi dans la suite de cette description deux types de productions : les productions simples et les productions qualifiées. Les productions dites simples sont les productions qui ne comportent pas ou ne sont pas associées à un nom qualifié (au contraire d'une production comme StartElement person). Ces productions sont donc caractérisées uniquement par un type d'événement général, ce type d'événement pouvant être désigné par un nom (par exemple fin d'élément) ou par un nombre. S'il est plus simple lorsque 16

l'on parle d'utiliser des noms pour désigner des événements, il est plus simple, en informatique, d'utiliser des nombres, et les interfaces XML définissent généralement un nombre pour chaque événement. Dans le cas de StAX par exemple, l'événement nommé fin d'élément équivaut au nombre 2 et celui nommé caractère vaut 4. Ainsi, lorsque l'on considère un type d'événement pour lequel les productions ne sont pas qualifiées, le nombre désignant cet événement suffit à le caractériser, et il est donc efficace d'obtenir la production décrivant cet événement en utilisant ce nombre comme un index dans un tableau. A cet effet, on construit, en même temps que chaque grammaire associée au document à traiter, un tableau de productions simples, chaque production se situant à l'index égal au nombre désignant l'événement qu'elle décrit (l'événement fin d'élément est désigné par le nombre 2 et la production le décrivant se trouve donc à l'index 2 dans ce tableau). Un tel tableau est illustré par la table 020 où l'on distingue les deux événements EndElement et Characters aux index respectifs 2 et 4. Une grammaire ne contient pas nécessairement une production pour chaque type d'événement XML, aussi certaines cellules du tableau peuvent-elles rester vides. Cela ne pose pas de problème puisque cela signifie que les événements correspondant à ces index ne sont pas censés se produire (cas d'une utilisation pour vérifier la conformité d'un document XML, par exemple). Dans le cas où ils se produisent, une création de production et une mise à jour de la table 020 peuvent être prévues (cas de la compression d'un document XML, par exemple).

Sur la figure 1, le tableau 020 des productions simples comporte arbitrairement six cellules, mais il peut en comporter plus (autant qu'il existe de types d'événement XML dans la représentation adoptée par l'application). L'avantage d'un tel tableau est de permettre un accès direct et efficace aux productions sans surcoût de calculs.

Les productions dites qualifiées (comme StartElement person) sont des productions associées à des types de données groupant un type d'événement général et une propriété spécifique de cet événement, cette 17

propriété définissant de la sorte un contexte. Pour ces productions, on construit une table de hachage (tableau 030). Au contraire des mécanismes conventionnels, l'invention limite le remplissage de la table de hachage 030 avec les seules productions dites qualifiées. Ainsi, on conserve le tableau 020 et un traitement plus rapide des événements associés aux productions simples. D'autre part, si l'on considère plusieurs types de productions qualifiées (des productions StartElement désignant des débuts d'éléments et des productions Attribut désignant des attributs), il est intéressant d'utiliser autant de tables de hachage que de types de productions qualifiées. Un type de production se rapportant aux productions visant un même type d'événement général avec des propriétés (informations contextuelles) différentes. En effet, les tables considérées sont alors plus petites, et offrent des performances supérieures, par exemple un temps d'accès moindre aux productions. Toutefois, ces productions sont régulièrement appelées dans le même ordre (du fait de la redondance du fichier XML), et il est ainsi intéressant de conserver les transitions entre deux de ces productions. Pour ce faire, on utilise un autre tableau. En l'espèce, le tableau 040 représente les transitions d'une production qualifiée vers une autre. De même qu'il est avantageux d'utiliser une table de hachage par type de production qualifiée, il est intéressant de considérer les transitions entre productions qualifiées de même type, c'est-à-dire d'un début d'élément vers un autre début d'élément, ou bien d'un attribut vers un autre attribut. En effet, de cette manière, on sépare mieux les différents cas et une variation des attributs, par exemple, n'a alors pas d'impact sur les transitions entre débuts d'éléments. Le traitement à l'aide de ce tableau 040 est alors plus efficace. Les transitions consistent en un lien d'une production vers une autre. Selon l'invention, lorsque l'on cherchera à prédire la prochaine production, on s'appuiera sur la précédente production qualifiée utilisée pour identifier l'entrée pertinente dans le tableau 040. Différentes réalisations sont possibles : on peut ajouter une propriété prochaine production à chaque production, ou encore indexer les productions qualifiées et utiliser un tableau dans lequel, à l'index de la production précédente, se trouve l'index de la production suivante. 18

Suivant la manière dont on utilise les grammaires, il se peut que l'on ajoute dynamiquement des productions (c'est notamment le cas dans le format XML binaire standardisé par le groupe EXI du W3C). Dans ce cas, il est nécessaire de mettre à jour les différentes structures dynamiquement : si une production simple est ajoutée à la grammaire, alors on l'ajoute aussi au tableau 020 de production simple, et de manière analogue pour une production qualifiée on procède à l'ajout dans la table de hachage 030. En particulier, dans le cas du format standardisé par le groupe EXI, il se peut que l'on ajoute une nouvelle production simple bien qu'une production simple décrivant un événement de même type existe déjà. Ceci se produit lorsque l'on veut affecter une priorité plus élevée à une production (et donc la coder plus efficacement), et dans ce cas la production simple de même type et de priorité inférieure ne sera plus utilisée. La nouvelle production peut donc prendre la place de l'ancienne dans la table des productions simples 020 sans que cela ne pose de problème.

Le traitement selon l'invention des données du document XML peut être vu comme suit. Lorsque l'on rencontre un événement de type non qualifié (événement simple), on calcule l'index correspondant dans la table 020 et on détermine ainsi directement la production à appliquer pour le traitement de la donnée. Lorsque l'on rencontre un début d'élément (ou tout autre événement associé à une production qualifiée), on peut, à partir de la production utilisée pour le début d'élément précédent (ou pour le type de donnée précédent) et le tableau 040 des transitions, prédire la production adéquate.

La première fois, les prédictions ne peuvent pas être fournies puisqu'il faut initialiser les transitions, mais par la suite si l'on rencontre un début d'élément après un début d'élément person, on prédit qu'il faut utiliser la production StartElement firstName. Pour savoir si la prédiction est correcte, il suffit alors de vérifier que le nom du début d'élément rencontré est bien firstName. Si ce n'est pas le cas, on obtient, par défaut, la bonne production via la table de hachage 030 et le 19

calcul de hachage conventionnel correspondant. On garantit ainsi l'obtention de la production souhaitée même en cas de prédiction erronée. Cette configuration structurelle des données offre une souplesse d'utilisation pour prendre en compte de nouveaux éléments au fur et à mesure du traitement du document XML (cas de la compression de fichier XML, par exemple). Par exemple, un nouvel élément middleName peut apparaître entre firstName et lastName. Ainsi, on crée une nouvelle production associée à StartElement middleName et on met à jour la table 040 des transitions. Notamment, la transition de StartElement firstName vers StartElement lastName n'est peut être plus valide, et de nouvelles transitions StartElement firstName -* StartElement middleName StartElement middleName -* StartElement lastName sont établies. On remarquera qu'aucun problème de synchronisation n'existe (contrairement à des solutions à base de simples listes statiques), car les nouvelles transitions permettent de se rattacher aux événements déjà existants afin de poursuivre la prédiction événement par événement. On note également que le fait de mettre à jour une transition est très peu coûteux, et cela permet d'adapter les prédictions aux contenus rencontrés, ces contenus pouvant évoluer au sein d'un même document. Cette solution basée sur une mise à jour systématique des transitions donne en pratique d'excellents résultats, au contraire d'autres approches basées sur des calculs de statistiques destinées à l'élaboration d'une séquence de productions attendue, ces approches requérant plus de calculs et donc de temps.

Toutefois, il peut être intéressant de définir un mécanisme légèrement plus coûteux destiné à ne plus prendre en compte une transition lorsque celle-ci n'est pas suffisamment souvent vérifiée. Une autre variante consiste à fixer une transition et à ne plus la mettre à jour de manière à ce qu'elle soit valide dans le cas le plus fréquent. Ces variantes sont décrites ultérieurement. 20

En référence à la figure 2, il est maintenant décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau.

Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, reliée à une carte d'entrée/sortie (non représentée) et fournissant au dispositif de traitement d'information des données multimédia, éventuellement sous forme de documents XML. Le dispositif 50 comporte un bus de communication 51 auquel sont reliés : - Une unité centrale de traitement CPU 52 se présentant par exemple sous la forme d'un microprocesseur ; - Une mémoire morte 53 dans laquelle peuvent être contenus les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention ; - Une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en oeuvre de l'invention, notamment les tables et grammaires de la figure 1 ; - Un écran 55 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; 21

- Un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - Un lecteur de disquette 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 70 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - Une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des 10 données. Dans le cas de données audio, le dispositif 50 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 62. Le bus de communication 51 autorise une communication et une 15 interopérabilité entre les différents éléments inclus dans le dispositif 40 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50. 20 Les disquettes 52 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de traitement d'information, 25 é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. Le code exécutable permettant au dispositif de traitement d'information la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique 30 amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être 22

stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 48 par exemple) avant d'être exécuté. L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC). Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 1, 3 à 7b, pour mettre en oeuvre le procédé objet de la présente invention et constituer le dispositif objet de la présente invention. On propose, en référence à la figure 3, des étapes pour le traitement d'un document structuré, par exemple XML. A l'étape 100, on récupère des données D structurées du document 1 et une grammaire G.

Ces données et cette grammaire sont obtenues par une application désirant réaliser un traitement sur ces données à l'aide de cette grammaire, par exemple la validation de ces données par rapport à un schéma XML, ou bien leur compression. Comme rappelé précédemment, au cours de ce traitement, les données sont vues comme des événements, et il est nécessaire de trouver la production P décrivant chaque événement considéré afin de réaliser un des traitements susmentionnés. A l'étape 110, on évalue si l'on a atteint la fin des données. 23

Dans l'affirmative (sortie OUI), le traitement prend fin à l'étape 190. Dans la négative (sortie NON), on obtient un événement EVT suivant à l'étape 120 à l'aide d'un module d'extraction de données du document, par exemple un parseur XML.

A l'étape 130, considérant l'événement extrait, on récupère une production P de G décrivant cet événement. Il convient de remarquer que la production P peut être nulle si aucune production adéquate n'a été trouvée. Dans ce cas, on s'adapte à la finalité souhaitée pour produire des informations complémentaires adaptées. Pour prendre l'exemple de la validation XML, si on ne trouve pas de production adéquate, cela peut signifier que les données ne sont pas conformes au schéma. Dans l'exemple de l'encodage/compression, on crée alors une production correspondante à partir d'une production par défaut. A l'étape 140, on procède au traitement relatif à l'événement EVT et à la production P.

Puis, on obtient la grammaire G suivante à l'étape 150, dans le cas où plusieurs grammaires sont prévues pour chaque élément. Il se peut que la grammaire suivante soit la même que la grammaire courante, cela dépend des grammaires que l'on utilise et de la production P considérée. Dans le cas où P correspond au début d'un élément, il est courant que la grammaire suivante soit la grammaire associée à cet élément. On retourne alors à l'étape 110 pour procéder au traitement des autres données du document. On décrit à présent plus en détail l'étape 130 de récupération/obtention de la production P de G décrivant l'événement extrait EVT, en référence à la figure 4. En partant de l'événement EVT (étape 200), on commence, à l'étape 210, par déterminer si l'événement EVT nécessite une prédiction. Cette détermination est notamment fonction du contexte dans lequel l'événement extrait EVT s'inscrit et donc du type d'événement concerné. Ainsi, s'il s'agit d'un type d'événement décrit par une production simple (par exemple un événement qui n'a pas une propriété spécifique à un contexte, notamment un événement qui n'est pas défini par un nom en complément de son type), 24

l'invention propose un traitement sans prédiction. Si en revanche il s'agit d'un type d'événement décrit par une production qualifiée et donc présentant une propriété dont on tient compte, par exemple le nom, l'invention propose alors une prédiction.

Comme on le verra par la suite, notamment en lien avec les figures 7a et 7b, on peut convenir, dans certaines situations, de ne pas procéder à la prédiction d'une production qualifiée (production dite "opaque"). L'information correspondante peut être contenue dans une valeur mémorisée, par exemple un ratio.

S'il n'est pas nécessaire de déterminer une prédiction, on passe à l'étape 220 durant laquelle on obtient la production P recherchée sans prédiction, telle que décrite ci-après en lien avec la figure 5. Inversement, si une prédiction est nécessaire, on obtient la production P en effectuant une prédiction à l'étape 230, telle que décrit ci-après en lien avec la figure 6. Dans les deux cas, le traitement prend alors fin à l'étape 290. L'obtention d'une production P sans prédiction est illustrée par la figure 5. Deux cas sont à distinguer selon que l'événement correspond à une production simple ou qualifiée. Ainsi à l'étape 310, on détermine si l'événement à traiter est qualifié, c'est-à-dire dans l'exemple s'il porte un nom. Dans la négative (sortie NON), c'est-à-dire si l'événement correspond à une production simple, la production est obtenue, à l'étape 320, en utilisant le tableau de productions simples 020 lié à la grammaire G considérée et le type de l'événement EVT (sous forme de nombre). A cette fin, dans le cas où les données sont traitées suivant le modèle StAX, on détermine la valeur StAX de l'événement considéré et on lit l'entrée du tableau 020 correspondant à l'index de même valeur StAX. Dans l'affirmative (sortie OUI), c'est-à-dire lorsque l'événement correspond à une production qualifiée par exemple "opaque", on obtient, à l'étape 330, la production grâce aux mécanismes conventionnels, typiquement par le calcul d'une valeur de hachage à partir de l'événement à traiter et par la 25

récupération de la production dans la table de hachage 030 liée à la grammaire G et correspondant à l'index égale à la valeur de hachage. Dans les deux cas, le traitement prend alors fin à l'étape 390. L'obtention d'une production P avec prédiction est illustrée par la figure 6. Partant de l'événement EVT à l'étape 400, on commence par obtenir, à l'étape 410, la production P résultat de la prédiction et illustré ci-après en lien avec la figure 7a. Cette obtention fait intervenir la production précédente utilisée (celle déterminée lors du traitement de l'événement précédent ou de l'événement de même type précédent de l'étape 120) que l'on note par la suite P_Prec. Il convient de souligner que dans le cas où l'on gère distinctement les différents types de productions qualifiées (séparation entre débuts d'éléments et attributs par exemple), on conserve la production précédente pour chaque type de production qualifiée (production précédente de type StartElement et production précédente de type Attribute). On évalue ainsi, à l'étape 420, si la production P obtenue à l'étape 410 décrit l'événement EVT, ce qui consiste, dans l'exemple, à vérifier que le nom associé à l'événement EVT et le nom qualifiant la production P sont bien les mêmes. Suivant la manière dont on construit les prédictions, il peut aussi être nécessaire de vérifier que les types d'EVT et de P coïncident, mais si l'on traite les prédictions liées à chaque type d'événement séparément, alors ce n'est pas nécessaire. Concrètement, si l'on gère distinctement les transitions entre productions StartElement et les transitions entre productions Attribute, une transition est nécessairement entre deux productions StartElement ou entre deux productions Attribute (et non entre une production StartElement et une production Attribute), par conséquent si l'on prédit une production StartElement, on est sûr que le résultat est une autre production StartElement.

En cas de prédiction correcte (sortie OUI), on indique que lors de la prochaine prédiction, il faudra utiliser P comme production précédente; c'est-à- 26

dire que l'on mémorise, à l'étape 470, comme production précédente P_Prec la prédiction obtenue à l'étape 410. Le traitement prend alors fin à l'étape 490. Le traitement de l'étape 140 est ainsi réalisé à l'aide de la production P, également mémorisée dans 5 P_Prec. En cas de prédiction incorrecte (sortie NON), on détermine, à l'étape 430, si la production précédemment utilisée peut se répéter, à l'aide d'un drapeau prévu à cet effet dans la production. Le fait qu'une production qualifiée se répète signifie que pour une 10 grammaire donnée, la même production qualifiée est utilisée plusieurs fois à la suite dans le document. C'est par exemple le cas si l'on a une liste de personnes : en effet, dans la grammaire contenant la production décrivant le début de l'élément personne, on utilise d'abord cette production, puis celle désignant la fin d'élément (production simple), et de nouveau celle désignant le 15 début de l'élément personne. Du point de vue des productions qualifiées, on constate donc que la production StartElement personne se répète au niveau de cette grammaire (on ne prend en compte que les productions qualifiées de cette grammaire, et les éventuelles productions qualifiées utilisées pour le contenu de l'élément personne ne sont pas concernées û elles relèvent d'une autre 20 grammaire (celle décrivant le contenu de l'élément personne)). Il est intéressant de détecter les productions qui se répètent et de les traiter indépendamment des prédictions car il arrive régulièrement qu'un élément se répète un certain nombre de fois (ce nombre pouvant être variable) puis qu'un autre élément lui succède. On a alors deux types de transitions 25 différentes : d'une part, des transitions de l'élément qui se répète vers lui-même ; d'autre part, une transition de l'élément qui se répète vers l'élément (distinct) qui lui succède. En traitant indépendamment les répétitions, on conserve la possibilité de définir une transition vers un autre élément tout en traitant efficacement le cas où la transition n'est pas valide. 30 Selon l'invention, on mémorise alors les transitions vers un autre élément au moyen de la table 040 et les répétitions au moyen d'un indicateur, 27

par exemple un drapeau, prévu au niveau de chaque production concernée, comme décrit ci-après. Si la production précédemment utilisée peut se répéter (sortir OUI à l'étape 430), on détermine, à l'étape 440, si elle décrit l'événement considéré.

Dans l'affirmative (sortie OUI à l'étape 440), la production cherchée est trouvée et le traitement prend alors fin à l'étape 490. Le traitement de l'étape 140 est ainsi réalisé à l'aide de la production P, également mémorisée dans P_Prec. On note en effet qu'il n'est pas nécessaire de paramétrer P comme la dernière production utilisée puisque P_Prec est déjà égale à P.

Dans la négative (sortie NON à l'étape 440) ou si la production précédemment utilisée ne peut pas se répéter (sortie NON à l'étape 430), le traitement se poursuit à l'étape 450 par l'obtention de la production P, de façon conventionnelle, via la table de hachage 030. On poursuit alors avec la mise à jour d'informations de prédiction, lors de l'étape 460 telle que décrite ci-après en lien avec la figure 7b. On prend alors en compte la production P en tant que prochaine production précédente à utiliser pour la prédiction relative à l'événement suivant. Le traitement prend alors fin à l'étape 490. Le traitement de l'étape 140 est ainsi réalisé à l'aide de la production P, également mémorisée dans P_Prec. Les figures 7a et 7b présentent le traitement des prédictions avec d'un côté l'obtention d'une prédiction (figure 7a), et de l'autre la mise à jour des informations de prédiction (figure 7b).

En ce qui concerne l'obtention de la prédiction P pour un événement EVT, on part de l'événement EVT et de la production précédente P_Prec à l'étape 500. On présente ici comment on obtient la production prédite à partir de la production précédente lors de l'étape 510.

La manière d'obtenir la production prédite dépend de la manière dont on gère les transitions entre productions : si l'on utilise une propriété production suivante pour chaque production, alors c'est cette production 28

indiquée dans la production P_Prec qui est la prédiction. Si on utilise un tableau de transitions 040 où les productions sont indexées et où, à l'index de chaque production, on trouve la production suivante prédite, alors on cherche à obtenir l'index de la production précédente P_Prec et à partir de celui-ci la production prédite correspondant à la production suivante qui lui est associée dans le tableau. Dans le cas du tableau avec index, plutôt que de conserver la production précédente, il est plus avantageux de ne conserver que son index dans P_Prec. Le traitement s'achève alors à l'étape 520.

En ce qui concerne la mise à jour des informations de prédiction de l'étape 460, on débute par la comparaison, à l'étape 560, de la production précédente P_Prec avec la production courante P qui décrit l'événement courant. En cas de productions différentes (sortie OUI à l'étape 560), cela signifie que la transition concernant P_Prec n'est pas valide, et on met donc à jour cette transition de manière à ce que P_Prec mène vers P (étape 570). Cette mise à jour peut être soumise à conditions comme, par exemple, un nombre suffisant d'occurrence de cette transition ou un ration de cette transition par rapport à une transition concurrente (deux transitions sont concurrentes lorsqu'elles partent d'une même production mais sont à destination de productions différentes) supérieur à 1. On peut également prévoir de fixer une fois pour toute une transition sans permettre sa substitution par une transition concurrente. Cette information de nouvelle transition sera utilisée la prochaine fois où l'on aura à obtenir une prédiction à partir de P_Prec. Le traitement prend alors fin à l'étape 590. En cas de productions identiques (sortie NON à l'étape 560), cela signifie que la même production est utilisée plusieurs fois de suite dans la grammaire considérée. On ajoute donc, à l'étape 580, à cette production l'information qu'elle peut se répéter, par exemple en passant un indicateur drapeau d'une position nulle '0' à une position active '1", ceci afin de pouvoir traiter efficacement les cas de répétition. 29

Puis, le traitement prend fin à l'étape 590. Dans une variante, on cherche à gérer une propriété d'opacité des productions. Le principe de l'opacité consiste à considérer une production ou une transition comme opaque lorsque la prédiction réalisée à partir de cette production n'est pas suffisamment souvent correcte. Dans ce cas, on renonce à réaliser une prédiction. Une manière de gérer l'opacité consiste à prendre en compte pour une production le nombre de prédictions réalisées et le nombre d'échecs rencontrés. Cela signifie qu'à l'étape 510, on incrémente un compteur associé à la production qui représente le nombre de prédictions réalisées ; d'autre part, au lieu de mettre à jour la transition (étape 570) systématiquement dans le cas où la production précédente et la production courante diffèrent, il faut alors commencer par incrémenter le compteur des échecs de prédiction, puis comparer le taux d'échecs à un seuil préfixé à partir duquel une production doit devenir opaque. Le gain en efficacité obtenu par l'utilisation des transitions étant de l'ordre de 5 à 10 (cela dépend des données traitées et de la mise en oeuvre, en particulier concernant les tables de hachage utilisées), on peut par exemple prendre un seuil de 80% d'échecs comme seuil minimal pour définir une production comme opaque. Il est avantageux de définir un nombre minimal de prédictions effectuées avant de prendre en compte le taux d'échecs, car ce taux peut par exemple être de 100% en cas d'échec pour la première prédiction sans pour autant que cela soit représentatif des données (toutes les prédictions suivantes peuvent être correctes). Un seuil de 10 prédictions effectuées peut être une bonne valeur. D'autres solutions sont possibles pour gérer l'opacité, par exemple en prenant en compte uniquement le nombre d'échecs et en fixant un seuil absolu (on décide par exemple qu'au bout de 10 échecs, la production devient opaque). On note, cependant, que la gestion de l'opacité implique un coût supplémentaire dans le procédé de prédiction, et cela ralentit donc l'obtention 30

de cette prédiction. Dans le cas où une production devient opaque, le gain de temps procuré par les prédictions non-calculées peut être supérieur à la perte de temps occasionnée par la gestion de l'opacité, cependant en règle générale on constate qu'il est plus avantageux de ne pas prendre en compte l'opacité.

Si en revanche on a une connaissance particulière sur les données que l'on va traiter, cette connaissance permettant de supposer qu'un certain nombre de prédictions ne sont pas intéressantes à calculer car les données correspondantes sont particulièrement irrégulières, alors on peut choisir d'utiliser l'opacité. Pour cette raison, il est intéressant d'intégrer l'opacité uniquement comme une option, cette option pouvant être activée ou désactivée par l'intermédiaire d'une interface définie par l'application. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (25)

REVENDICATIONS

1. Procédé d'accès à une production parmi une pluralité de productions d'au moins une grammaire, ladite pluralité de productions comprenant un premier groupe de productions associées à un premier groupe d'événements définis chacun par un type d'événement et une information contextuelle, et un deuxième groupe de productions associées à un deuxième groupe d'événements distinct du premier groupe, lesdits événements décrivant des données hiérarchisées d'un document électronique structuré, ledit procédé comportant : a) une étape consistant à déterminer (210) si un événement considéré est du premier groupe ; b) dans l'affirmative, une étape de prédiction (230, 410, 510) d'une production associée audit événement considéré.

2. Procédé selon la revendication précédente, comprenant une étape de vérification (420) de ladite prédiction.

3. Procédé selon la revendication précédente, comprenant, en cas de vérification négative, une étape de détermination (450) d'une production à l'aide d'une table de hachage (030).

4. Procédé selon l'une des revendications précédentes, comprenant une mise à jour (460) d'informations de prédiction.

5. Procédé selon l'une des revendications précédentes, comprenant, en cas de détermination négative à l'étape a), la détermination (220, 320) d'une production associée à l'événement considéré et comprenant le calcul d'une donnée d'identification dudit événement considéré et la récupération d'une production dans une table (020) à partir de ladite donnée d'identification.

6. Procédé selon la revendication précédente, dans lequel les productions du deuxième groupe sont mémorisées dans un tableau (020), 30 chacune à l'index correspondant à ladite donnée d'identification.

7. Procédé selon l'une des revendications précédentes, dans lequel ladite information contextuelle comporte, dans ledit événement, un nom 32 associé à un élément des données hiérarchisées de telle sorte que la production associée audit événement est définie dans le contexte dudit élément.

8. Procédé de traitement d'un document électronique comprenant des données hiérarchisées organisées en une pluralité d'éléments pouvant être décrits par un ensemble d'événements en utilisant au moins une grammaire comportant des productions, ledit procédé comportant : i) une étape d'extraction (120) d'un événement à traiter ; ii) une étape d'accès à une production associée audit événement à 10 traiter conformément au procédé selon l'une quelconque des revendications précédentes.

9. Procédé selon la revendication précédente, dans lequel on réitère les étapes i) et ii) pour une pluralité d'événements dudit document.

10. Procédé selon la revendication précédente, dans lequel la 15 grammaire comprend au moins une transition associant une production dite "précédente" à une production dite "suivante", ladite prédiction à l'étape b) comprenant la détermination d'une production suivante associée à une production décrivant un événement traité lors d'une itération précédente.

11. Procédé selon la revendication précédente, dans lequel les 20 événements dudit document sont regroupés en différents types, ladite prédiction d'un événement d'un type étant effectuée à partir de la production associée au dernier événement de même type traité.

12. Procédé selon la revendication 10 ou 11, dans lequel ladite transition est mémorisée dans une table de transitions (040). 25

13. Procédé selon l'une des revendications 10 à 12, dans lequel ladite étape d'accès est conforme au procédé selon la revendication 4 et dans lequel ladite mise à jour (460) comprend la mémorisation d'une transition entre la production associée à l'événement précédemment traité et la production déterminée à l'aide de la table de hachage (030). 30

14. Procédé selon l'une des revendications 10 à 13, comprenant une étape d'inactivation d'une transition.33

15. Procédé selon l'une des revendications 9 à 14, dans lequel ladite étape d'accès est conforme au procédé selon l'une des revendications 2 et 3 et dans lequel : a) en cas de vérification négative, on détermine (430) si la production associée 5 à l'événement précédemment traité peut se répéter, et R) en cas de détermination positive à l'étape a), on compare (440) l'événement associé à la production précédemment traitée avec l'événement extrait.

16. Procédé selon la revendication 15, dans lequel, en cas de comparaison négative à l'étape R), on détermine (450) une production associée 10 à l'événement extrait à partir d'une table de hachage (030),

17. Procédé selon la revendication 15, dans lequel, en cas de détermination négative à l'étape a), on détermine (450) une production associée à l'événement extrait à partir d'une table de hachage (030), on compare (560) la production associée à l'événement précédemment traité et la 15 production obtenue à partir de la table de hachage et on met à jour (580) un indicateur de répétition dans ladite production en cas de comparaison positive.

18. Dispositif d'accès à une production parmi une pluralité de productions d'au moins une grammaire, ladite pluralité de productions comprenant un premier groupe de productions associées à un premier groupe 20 d'événements définis chacun par un type d'événement et une information contextuelle, et un deuxième groupe de productions associées à un deuxième groupe d'événements distinct du premier groupe, lesdits événements décrivant des données hiérarchisées d'un document électronique structuré, ledit dispositif comportant : 25 a) un premier moyen de détermination apte à déterminer si un événement considéré est du premier groupe ; b) un moyen de prédiction apte à prédire une production associée à un événement du premier groupe.

19. Dispositif selon la revendication précédente, dans lequel ledit 30 moyen de prédiction comprend des transitions associant une production dite "précédente" à une production dite "suivante", 34 le moyen de prédiction étant apte à déterminer la production suivante associée à une production décrivant un événement traité précédemment.

20. Dispositif selon la revendication 19, dans lequel le moyen de prédiction comprend au moins une table référençant lesdites transitions.

21. Dispositif selon la revendication 19, dans lequel au moins une production référence une production suivante de sorte à former implicitement une desdites transitions.

22. Dispositif selon l'une des revendications 18 à 21, comprenant un moyen de vérification des prédictions dudit premier moyen de prédiction et un deuxième moyen de détermination d'une production apte à déterminer une production à partir d'une table de hachage lorsque la prédiction est erronée.

23. Dispositif selon l'une des revendications 18 à 22, comprenant un troisième moyen de détermination d'une production associée à un événement du deuxième groupe, ledit troisième moyen de détermination comprenant une table associant, à une donnée d'identification d'un événement, une production décrivant ledit événement.

24. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de traitement conforme à l'une quelconque des revendications 1 à 17, lorsque le programme est chargé et exécuté par le système informatique.

25. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de traitement selon l'une quelconque des revendications 1 à 17, lorsqu'il est chargé et exécuté par le microprocesseur.