FR 2881541 A1 20060804 FR 0501038 A 20050202 2881541 1 La présente invention se rapporte au traitement d'un flot de données décrit en langage de balisage, par exemple de type XML. XML, acronyme de eXtensible Markup Language c'est-à-dire langage à balise extensible, est un langage informatique permettant de 5 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 des documents XML. 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 geneiatorou 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 forXML) 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 2881541 2 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 10 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 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 2881541 3 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 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 de taille importante, 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 qüé souhaite en faire l'application. Dans ce cas, l'application doit 20 transformer cette représentation générique en une représentation qui lui est 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 SA):, 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 2881541 4 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 , l'application doit retrouver l'état d'avancement de ses traitements, effectuer les traitements impliqués par l'événement correspondant à l'élément titre , puis de nouveau mémoriser l'état d'avancement de ses traitements. 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 30 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 2881541 5 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énement 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 transrnettant 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. La syntaxe XML est définie par un ensemble de règles. Certaines de ces règles décrivent de manière générale la syntaxe XML. Par exemple, une balise ouvrante commence par , tandis qu'une balise fermante commence par Enfin d'autres règles précisent encore les détails de la syntaxe XML. Par exemple, le nom d'une balise doit commencer par une lettre, _ ou : et peut se continuer par une série de lettres, chiffres, . , - , _ , : , caractères de combinaison ou caractères d'extension. L'ensemble de ces règles permet de définir une classe de document qui contient les documents conformes au standard XML. Lors du traitement (ou parsing) d'un document XML, ou de sa génération, il convient de vérifier l'ensemble de ces règles pour s'assurer que le 30 document XML traité ou généré est bien conforme aux règles XML. Cependant, la vérification de l'ensemble de ces règles constitue une charge de calcul importante pour le parseur ou le générateur XML. 2881541 6 En outre, il apparaît que ces règles peuvent être divisées en deux catégories: celles qui définissent la base de la syntaxe, qui ne peuvent être ignorées lors du traitement ou de la génération d'un document XML et celles qui se contentent de préciser cette syntaxe et dont la vérification n'est pas nécessaire, si l'on suppose que le document XML traité est correct ou que l'application générant le document XML fournit des données correctes. Par exemple, il est impératif d'utiliser la règle spécifiant qu'une balise ouvrante commence par pour repérer les balises ouvrantes lors du traitement d'un document XML, tout comme il est impératif d'utiliser cette même règle lors de la génération d'un document XML pour indiquer les balises ouvrantes. Par contre, il n'est pas nécessaire de vérifier que le nom d'une balise ne contient que des caractères autorisés, si l'on suppose que le document XML duquel elle provient est correct ou si l'on suppose que l'application fournissant ce nom pour la génération d'un document XML est fiable. Le Demandeur s'est posé le problème d'améliorer l'analyse et/ou la génération de document XML, par rapport aux analyseurs/générateurs de l'art antérieur. La présente invention apporte justement une solution à ce problème. 20 Elle vise un procédé d'analyse d'un flot de données dans un langage de balisage, comprenant au moins une balise. Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: - définition au préalable d'au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières et secondes conditions étant ordonnées selon un ordre d'importance choisi pour la validité de traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - obtention d'au moins une caractéristique d'une balise du flot de 30 données; première vérification que la au moins une caractéristique respecte les premières conditions de traitement; 2881541 7 - en cas de première vérification positive, vérification d'une condition de nécessité d'une seconde vérification; - en cas de vérification positive de la condition de nécessité, envoi de la au moins une caractéristique à un filtre de vérification apte à effectuer une 5 étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement. Ainsi, il peut être utile de ne pas vérifier systématiquement toutes les règles de traitement du flot de données lors de l'analyse du flot de données. Pour pouvoir vérifier les règles secondaires, la présente invention propose d'ajouter des filtres de vérification. Ainsi, la vérification de ces règles secondaires est rendue conditionnelle à une condition de nécessité qui, si elle est respectée, permet de diminuer le temps de traitement d'un flot de données. L'invention s'applique plus particulièrement à un langage de balisage de type XML. En pratique, les premières conditions de traitement sont relatives à des règles de base de la syntaxe des données XML nécessaires pour le traitement d'une caractéristique XML du flot de données, tandis que les secondes conditions sont relatives à des règles de précision sur la syntaxe des données XML pour le traitement d'une caractéristique XML. Par exemple, la condition de nécessité de seconde vérification est la fiabilité d'une application mettant en oeuvre le flot de données. Selon une réalisation, en cas de vérification négative de la condition de nécessité, le procédé comporte une étape d'envoi de la au moins une caractéristique du flot de données à une application de traitement du flot de données apte à vérifier les secondes conditions de traitement. L'invention vise également un procédé de génération d'un flot de données dans un langage de balisage, comprenant au moins une balise. Selon une autre caractéristique importante de l'invention, le procédé comprend les étapes suivantes: - définition au préalable d'au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières et secondes conditions étant ordonnées selon un ordre d'importance pour la 2881541 8 validité de traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - génération d'au moins une caractéristique d'une balise du flot de données; - vérification d'une condition de nécessité d'une seconde vérification; - en cas de vérification positive de la condition de nécessité, envoi de la au moins une caractéristique à un filtre de vérification apte à effectuer une étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement; - en cas de seconde vérification positive, première vérification que la au moins une caractéristique respecte les premières conditions de traitement. Ainsi, comme pour l'analyse, il peut être utile de ne pas vérifier systématiquement toutes les règles de traitement du flot de données lors de la génération du flot de données. Pour pouvoir vérifier les règles secondaires, la présente invention propose d'ajouter des filtres de vérification. Ainsi, la vérification de ces règles secondaires est rendue conditionnelle à une condition de nécessité qui si elle est respectée permet de diminuer le temps de génération d'un flot de données. En pratique, la condition de nécessité de seconde vérification est la fiabilité des données fournies par la génération du flot de données ou la fiabilité de l'application génératrice desdites données. Selon une réalisation, en cas de vérification négative de la condition de nécessité, le procédé comporte une étape d'envoi de la au moins une caractéristique du flot de données à une application de traitement du flot de données apte à vérifier les secondes conditions de traitement. La présente invention a également pour objet un dispositif d'analyse d'un flot de données dans un langage de balisage, comprenant au moins une balise. Selon une autre caractéristique importante de l'invention, le dispositif de traitement comprend au niveau dudit filtre de traitement: -des moyens pour définir au préalable au moins des premières et secondes conditions de traitement de données XML ordonnées selon un ordre 2881541 9 d'importance choisi, les premières conditions étant plus importantes que les deuxièmes; - des moyens d'obtention pour obtenir au moins une caractéristique d'une balise du flot de données; - des premiers moyens de vérification pour vérifier que la au moins une caractéristique respecte les premières conditions; - des moyens de traitement pour, en cas de première vérification positive des premières conditions de traitement, vérifier une condition de nécessité de seconde vérification; et - des moyens d'envoi propres, en cas de vérification négative de la condition de nécessité, à envoyer la au moins une caractéristique à un filtre de vérification apte à effectuer un étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions. La présente invention a également pour objet un dispositif de 15 génération d'un flot de données dans un langage de balisage, comprenant au moins une balise, caractérisé en ce qu'il comprend: - des moyens pour définir au préalable au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières et secondes conditions étant ordonnées selon un ordre d'importance pour la validité du traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - des moyens pour générer au moins une caractéristique d'une balise du flot de données; - des moyens de vérification pour vérifier une condition de nécessité d'une seconde vérification; - des moyens de traitement pour, en cas de vérification positive de la condition de nécessité, envoyer la au moins une caractéristique à un filtre de vérification apte à effectuer une seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement et, en cas de seconde vérification positive, lesdits moyens de traitement sont aptes à vérifier que la au moins une caractéristique respecte les premières conditions de traitement. 2881541 10 La présente invention a également 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é d'analyse ou de génération mentionné 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é d'analyse ou de génération mentionné 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 15 lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure 1A montre schérnatiquement un dispositif de type ordinateur pour la mise en oeuvre du procédé selon l'invention; - la figure 1B montre un document XML; - la figure 1C montre un document SOAP avec ses différentes 20 parties; - la figure 2 représente un organigramme illustrant les étapes du procédé d'analyse d'un document XML selon l'invention; - la figure 3 présente le processus de génération d'un document XML selon l'invention; - la figure 4 décrit l'analyse d'un message SOAP selon l'invention; - la figure 5 décrit la génération d'un message SOAP selon l'invention; - la figure 6 présente l'ensemble des modules applicatifs analysant un document XML selon l'invention; et - la figure 7 présente l'ensemble des modules applicatifs générant un document XML selon l'invention. 2881541 11 En référence à la figure 1A, on a décrit un appareil programmable 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 comportant des registres 208 adaptés à enregistrer des variables et paramètres (p, P, i, I) créés et modifiés au cours de 10 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. 2881541 12 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 rnise en oeuvre de l'invention. Il 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 1B, on a représenté un document XML dont la structure générale est correcte (et qui pourrait donc être traité par un parseur XML simplifié, ou généré par un générateur XML simplifié), mais comportant de nombreuses erreurs de détails. Ainsi par exemple, le préfixe de la première balise ouvrante, ns , débute par le chiffre 1 , ce qui n'est pas autorisé. Ensuite, le nom local de l'attribut de cette même balise débute par le caractère _ qui ne peut se trouver en début de nom local pour une balise ou un attribut. Enfin, la valeur de l'attribut comporte le caractère , le préfixe et nom local sont 2881541 13 correctement séparés : , tandis que le nom de la balise et la définition de l'attribut sont séparés par un espace. Ainsi, la structure générale de cette première balise est suffisamment correcte pour pouvoir être traitée comme un document XML. En référence à la figure 1C, on a représenté un document conforme au protocole SOAP (Simple Object Access Protocol) avec ses différentes parties. La structure générale du document SOAP est spécifiée par la norme SOAP: ainsi les éléments env:Envelope et env:Body sont nécessairement présents, tandis que l'élément env:Header est optionnel, mais ne peut être remplacé par un autre élément. Un utilisateur du protocole SOAP ne peut ajouter des informations supplémentaires qu'à l'intérieur des éléments env:Body et env:Header . Une application traitant des documents SOAP doit donc vérifier la présence des deux éléments obligatoires et la présence optionnelle de l'élément env:Header . Il n'est donc pas utile, au niveau du parseur XML, de vérifier que le nom de ces éléments respecte bien la syntaxe XML, il suffit de vérifier au niveau du parseur SOAP que ce sont bien les noms attendus. Par contre, les éléments laissés libres pour l'utilisateur doivent être vérifiés en détail. En référence à la figure 2, on a représenté le processus de traitement d'un document XML selon l'invention. Quand une application utilisant un document XML demande un nouvel événement au parseur (étape E200), le parseur traite dans un premier temps le fichier contenant le document XML. Ce traitement consiste à examiner les caractères contenus dans le fichier à la position courante et à déterminer quel type de balisage XML est présent à cet endroit du fichier (étape E210). Le traitement (étape E220) comprend la vérification de certaines règles de syntaxe XML (implicitement ou explicitement). Ces premières règles constituent des premières conditions de traitement. En pratique de telles premières conditions sont importantes ou obligatoires pour le traitement correct d'une donnée XML. Par exemple, elles portent sur des critères de base relatifs à la syntaxe XML. Si la vérification de ces premières règles n'est pas concluante, leparseur retourne une erreur (étape E270), sinon il continue le traitement. Pour cela, le parseur crée un 2881541 14 nouvel événement représentant le type de balisage XML détecté (étape E230) , puis il transmet (étape E240) cet événement au filtre de vérification. Cet envoi est conditionnel à une vérification d'une condition de nécessité d'une seconde vérification. En pratique, cette condition de nécessité est par exemple la fiabilité de l'application d'où provient le document XML. Cette condition de nécessité peut être aussi la fiabilité de la source du document XML ou une volonté de rapidité d'exécution. Le filtre de vérification vérifie (étape E250) si les autres règles (moins importantes que celles appartenant aux premières règles) de syntaxe XML sont 10 bien vérifiées par l'événement. Les secondes conditions sont donc relatives à des règles précisant la syntaxe du langage XML et qui peuvent être ignorées si l'on suppose le document XML traité est correct. Si ce n'est pas le cas, le parseur retourne une erreur (étape E270) , sinon il retourne l'événement à l'application (étape E260). Si le filtre n'est pas 15 présent, les étapes E240 et E250 ne sont pas effectuées. Dans un autre mode de réalisation, le parseur XML peut après avoir vérifier les premières conditions de traitement, envoyer l'évènement analysé directement à l'application qui effectue directement ou indirectement (seulement en regardant si les noms correspondent aux noms attendus par exemple) la vérification des secondes conditions de traitement. En référence à la figure 3, on a représenté le processus de génération d'un document XML selon l'invention. Quand une application souhaite ajouter un fragment XML à un document XML, elle crée (étape E300) un nouvel événement représentant le fragment, qu'elle transmet au filtre de vérification (étape E310). Ce filtre vérifie (étape E320) un certain nombre de règles de syntaxe sur cet événement. En pratique, ces règles de syntaxe peuvent correspondre à celles dites moins importantes ou secondaires que les premières règles de syntaxe, dites obligatoires ou principales mentionnées en référence à la figure 2. Si cette vérification n'est pas concluante, le filtre retourne une erreur (étape E360), sinon, il transmet l'événement au générateur (étape E330). Le générateur tente alors de créer le fragment XML en accord avec les premières conditions de traitement qu'il aura 2881541 15 vérifié (étape E340). Si cette création n'est pas possible, c'est-à-dire si les premières conditions ne peuvent pas être vérifiées, il retourne une erreur (étape E360). Sinon, il génère effectivement le fragment XML dans le document XML (étape E350). Si le filtre n'est pas présent, les étapes E310 et E320 ne sont pas effectuées. En référence à la figure 4, on a décrit le traitement d'un message SOAP selon l'invention. Lors de la réception d'un message (étape E400), le parseur XML est configuré pour ne pas utiliser de filtre de vérification. Le parseur XML commence à traiter (étape E405) le début du message (la balise env:Envelope et éventuellement la balise env:Header Si elle est présente). Il est à noter que si la balise env:Header n'est pas présente, le processus continue directement à l'étape E450. Ensuite, le parseur XML va traiter chaque en-tête du message (étape E410). Pour chaque en-tête, le processus obtient l'application (étape E415) qui va réaliser le traitement (étape E430) de cet en-tête. Le parseur va vérifier (étape E420), qu'une condition de nécessité d'une seconde vérification est vérifiée. En pratique, cette condition de nécessité est par exemple la fiabilité de l'application d'où provient le document XML. Cette condition de nécessité peut être aussi la robustesse de la destination du document XML ou une volonté de rapidité d'exécution. Si cette application n'est pas considérée fiable le processus va ajouter (étape E425) un filtre de vérification au parseur. Dans les deux cas, il transmet l'en-tête à l'application pour que cet en-tête soit traité (étape E430) selon les premières étapes (E200, E210, E220) du procédé décrit à la figure 2. Ensuite, si le filtre a été ajouté au parseur, il est enlevé (étape E435) avant de continuer le traitement. S'il reste un autre en-tête non traité (étape E440) il est obtenu (étape E445) puis traité de la même manière (étapes E415 à E435). Sinon le traitement se poursuit à l'étape E450. La décision de la fiabilité d'une application peut être basée sur différents critères comme le fait qu'elle fasse partie du même ensemble de composants logiciels que l'invention, ou qu'elle soit homologuée par le fabricant du parseur. Quand l'ensemble des en-têtes a 2881541 16 été traité, le processus traite (étape E450) la suite du message (l'éventuelle balise fermante de env:Header et la balise ouvrante de env:Body ). Puis il ajoute (étape E455) le filtre de vérification au parseur avant de transmettre (étape E460) le message à l'application chargé de son traitement. Après le traitement du corps du message, le processus supprime (étape E465) le filtre de vérification et traite (étape E470) la fin du message (balise fermante env:Body et env:Envelope ). Il est à noter que le filtre de vérification est de préférence ajouté pour le contenu du message, car on considère que la plupart des applications traitant 10 le corps des messages SOAP ne sont pas fiables. Dans une autre mise en oeuvre de l'invention, la fiabilité de l'application traitant le corps du message peut être vérifiée avant de mettre en place si nécessaire le filtre de vérification. En référence à la figure 5, on a décrit la génération (étape E500) d'un message SOAP selon l'invention. Lors de la génération d'un message, le générateur XML est configuré pour ne pas utiliser de filtre de vérification. Le générateur XML commence à générer (étape E505) le début du message (la balise env:Envelope et éventuellement la balise env:Header Si le message comporte des en-têtes). Si le message ne comporte aucun en-tête, la génération se poursuit directement à l'étape E545. Sinon, le processus va générer chaque en-tête. Pour cela, il obtient une première application chargée de générer un en-tête (étape E510). Le générateur vérifie (étape E515), qu'une condition de nécessité d'une seconde vérification est respectée. En pratique, cette condition de nécessité est par exernple la fiabilité des données fournies pour la génération du document XML ou la fiabilité de l'application qui génère ces données. Si cette application n'est pas considérée comme fiable, un filtre de vérification est ajouté (étape E520) au générateur. Dans tous les cas, le message est passé (étape E525) à l'application générant l'en-tête pour qu'elle puisse ajouter l'en-tête dont elle est responsable. Si le filtre a été ajouté, il est alors retiré (étape E530). S'il reste un autre en- tête à générer (étape E535), l'application chargée de le générer est obtenue (étape E540), puis cet en-tête 2881541 17 est généré de la même manière (étapes E515 à E530). Quand tous les en-têtes on été générés, le processus génère (étape E545) la suite du message (balise fermante de env:Header , Si nécessaire, et celle ouvrante de env:Body ). Puis il ajoute (étape E550) le filtre de vérification au générateur. Le message est alors transmis (étape E555) à l'application générant le contenu afin qu'elle y ajoute le contenu. Puis le filtre de vérification est supprimé (étape E560) et la fin du message est générée (balise fermante de env:Body et balise fermante de env:Envelope ) (étape E565). Comme pour l'analyse d'un document XML, il est à noter que le filtre de vérification est de préférence ajouté pour le contenu du message, car on considère que la plupart des applications générant le corps d'un message SOAP ne sont pas fiables. En variante, la fiabilité de l'application générant le corps du message peut être vérifiée avant de mettre en place si nécessaire le filtre de vérification. En référence à la figure 6, on a représenté l'ensemble des modules applicatifs traitant un document XML selon l'invention. Le document XML est obtenu à partir d'un fichier 600 (il peut être aussi obtenu par un réseau ou par tout autre moyen). Ce document est traité par un parseur Pull 610 qui va générer un évènement pour chaque partie du document XML. Ce parseur Pull a la particularité de ne pas vérifier l'ensemble des règles XML, mais uniquement celles nécessaires à l'extraction des informations permettant de générer les événements (ainsi que les vérifications ne pouvant être effectuées par le filtre). Ensuite, les événements représentant le document XML sont transmis au filtre de vérification 620 qui effectue les vérifications non réalisées par le parseur Pull. Ce filtre 620 transmet à son tour les événements à l'application utilisatrice 630 du document XML. Le filtre 620 peut ou non être présent lors du traitement d'un document XML. Sa présence permet d'assurer la conformité complète du document XML. Son absence permet de diminuer le temps de traitement du document XML. En référence à la figure 7, on a représenté l'ensemble des modules applicatifs générant un document XML selon l'invention. Ces modules sont similaires à ceux de la figure 6, réalisant un rôle inverse. L'application 730 2881541 18 source de la génération crée des événements représentant le document XML et les transmet au filtre de vérification 720. Ce filtre 720 vérifie sur cet événement les règles de syntaxe qui ne sont pas vérifiées ou mises en oeuvres par le générateur (par exemple, la conformité du nom des balises, ...). Le filtre transmet alors ces événements au générateur XML 710, qui crée pour chaque événement le fragment XML le représentant. Ce fragment XML est ajouté au fichier 700 qui contiendra à la fin de la génération l'ensemble du document XML. Le filtre 720 peut ou non être présent lors de la génération d'un document XML. Sa présence permet d'assurer la conformité complète du document XML. Son absence permet de diminuer le temps de génération du document XML. Bien entendu, de nombreuses modifications peuvent être apportées à l'exemple de réalisation décrit précédemment sans sortir du cadre de l'invention. 19 REVENDICATIONS 1. Procédé d'analyse d'un flot de données dans un langage de balisage, comprenant au moins une balise, caractérisé en ce qu'il comprend les étapes suivantes: - définition au préalable d'au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières 10 et secondes conditions étant ordonnées selon un ordre d'importance pour la validité de traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - obtention d'au moins une caractéristique d'une balise du flot de données; - première vérification que la au moins une caractéristique respecte les premières conditions de traitement; - en cas de première vérification positive, vérification d'une condition de nécessité d'une seconde vérification; - en cas de vérification positive de la condition de nécessité, envoi de la au moins une caractéristique à un filtre de vérification apte à effectuer une étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement. 2. Procédé selon la revendication 1, caractérisé en ce que le langage 25 de balisage est un langage de type XML. 3. Procédé selon la revendication 2, dans lequel les premières conditions de traitement sont relatives à la syntaxe des données XML nécessaires pour le traitement d'une caractéristique XML du flot de données, tandis que les secondes conditions sont relatives à des règles de précision sur la syntaxe des données XML pour le traitement fiable d'une caractéristique XML. 2881541 20 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la condition de nécessité de seconde vérification est la fiabilité d'une application mettant en oeuvre le flot de données. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que en cas de vérification négative de la condition de nécessité, le procédé comporte une étape d'envoi de la au rnoins une caractéristique du flot de données à une application de traitement du flot de données apte à vérifier les secondes conditions de traitement. 6. Procédé de génération d'un flot de données dans un langage de balisage, comprenant au moins une balise, caractérisé en ce qu'il comprend les étapes suivantes: - définition au préalable d'au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières et secondes conditions étant ordonnées selon un ordre d'importance pour la validité de traitement du flot de données les premières conditions étant plus importantes que les deuxièmes; génération d'au moins une caractéristique d'une balise du flot de données; - vérification d'une condition de nécessité d'une seconde vérification; en cas de vérification positive de la condition de nécessité, envoi de la au moins une caractéristique à un filtre de vérification apte à effectuer une étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement; - en cas de seconde vérification positive, première vérification que la au moins une caractéristique respecte les premières conditions de traitement. 7. Procédé selon la revendication 6, caractérisé en ce que le langage de balisage est un langage de type XML. 2881541 21 8. Procédé selon la revendication 7, dans lequel les premières conditions de traitement sont relatives à la syntaxe des données XML nécessaires pour le traitement d'une caractéristique XML du flot de données, tandis que les secondes conditions sont relatives à des règles de précision sur la syntaxe des données XML pour le traitement fiable d'une caractéristique XML. 9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que la condition de nécessité de seconde vérification est la fiabilité des données fournies pour la génération du flot de données ou la fiabilité de l'application génératrice desdites données. 10. Procédé selon l'une des revendications 6 à 9, caractérisé en ce que en cas de vérification négative de la condition de nécessité, le procédé comporte une étape d'envoi de la au moins une caractéristique du flot de données à une application de traitement du flot de données apte à vérifier les secondes conditions de traitement. 11. Dispositif d'analyse d'un flot de données dans un langage de balisage, comprenant au moins une balise, caractérisé en ce qu'il comprend: - des moyens pour définir au préalable au moins des premières et secondes conditions de traitement de données XML, ordonnées selon un ordre d'importance choisi pour la validité de traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - des moyens d'obtention pour obtenir au moins une caractéristique d'une balise du flot de données; - des premiers moyens de vérification pour vérifier que la au moins une caractéristique respecte les premières conditions de traitement; - des moyens de traitement pour, en cas de première vérification positive des premières conditions de traitement, vérifier une condition de nécessité d'une seconde vérification; et 2881541 22 - des moyens d'envoi propres, en cas de vérification positive de la condition de nécessité, à envoyer la au moins une caractéristique à un filtre de vérification apte à effectuer un étape de seconde vérification que la au moins une caractéristique respecte les secondes conditions de traitement. 12. Dispositif selon la revendication 11, dans lequel les premières conditions de traitement sont relatives à la syntaxe des données XML, nécessaires pour le traitement d'une caractéristique XML du flot de données, tandis que les deuxièmes conditions sont relatives à des règles de précision sur la syntaxe des données XML, pour le traitement fiable d'une caractéristique XML. 13. Dispositif selon la revendication 11 ou la revendication 12, dans lequel les moyens d'envoi sont aptes, en cas de vérification négative de la condition de nécessité, à envoyer la au moins une caractéristique du flot de données à une application du traitement du flot de données apte à vérifier les secondes conditions de traitement. 14. Dispositif de génération d'un flot de données dans un langage de balisage, comprenant au moins une balise, caractérisé en ce qu'il comprend: - des moyens pour définir au préalable au moins des premières et secondes conditions de traitement de données du langage de balisage, lesdites premières et secondes conditions étant ordonnées selon un ordre d'importance pour la validité du traitement du flot de données, les premières conditions étant plus importantes que les deuxièmes; - des moyens pour générer au moins une caractéristique d'une balise du flot de données; - des moyens de vérification pour vérifier une condition de nécessité d'une seconde vérification; - des moyens de traitement pour, en cas de vérification positive de la condition de nécessité, envoyer la au moins une caractéristique à un filtre de vérification apte à effectuer une seconde vérification que la au moins une 2881541 23 caractéristique respecte les secondes conditions de traitement et, en cas de seconde vérification positive, lesdits moyens de traitement sont aptes à vérifier que la au moins une caractéristique respecte les premières conditions de traitement. 15. Dispositif selon la revendication 14, dans lequel les moyens de traitement comprennent en outre des moyens aptes, en cas de vérification négative de la condition de nécessité, à envoyer la au moins une caractéristique du flot de données à une application de traitement du flot de 10 données apte à vérifier les secondes conditions de traitement. 16. 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é selon les revendications 1 à 5 ou 6 à 10, lorsque ce programme est chargé et exécuté par un système informatique. 17. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé selon les revendications 1 à 5 ou 6 à 10, lorsque ce programme est chargé et exécuté par un système informatique.