PROCEDE ET SYSTEME DE CONFIGURATION DE DOCUMENTS

DOMAINE TECHNIQUE DE L'INVENTION

[0001] L'invention se rapporte à un procédé de configuration de documents, et à un système pour la mise en œuvre de ce procédé.

[0002] L'invention se rapporte au domaine de traitement de données, et plus particulièrement aux procédés et systèmes permettant de configurer des documents multiplateformes comportant des données audio, texte et/ou vidéo. Cette configuration est effectuée de sorte que ces documents soient décodables par toute application numérique telle qu'un navigateur Web, ou encore des applications aptes à interpréter des documents ayant des formats de type PDF (Portable Document Format), ou encore RTF (Rich Text Formattel) etc.

ETAT DE LA TECHNIQUE ANTERIEURE

[0003] En quelques décennies, Internet est devenu un réseau informatique mondial quasiment incontournable dans le domaine de la communication. Ce réseau de communication a pris une ampleur rapide en interconnectant des terminaux fixes ou mobiles dans le monde. Ainsi toute information est devenue accessible à partir de tout terminal n'importe où et à tout moment. Engendrant par conséquent, une augmentation conséquente de création et/ou d'ajout de pages Web dans ce système de transmission de l'information.

[0004] Dans un tel système, il est important de pouvoir créer et/ou convertir rapidement et facilement des documents en vue de leur diffusion par ce réseau de communication, en des formats qui soient accessibles par toute application ou terminal connecté à Internet.

[0005] II est conventionnellement connu dans l'art antérieur que les formats décodables par une application de type navigateur Web se rapportent à des langages informatiques de balisage notamment pour créer de l'hypertexte. De tels formats se rapportent par exemple à du HTML (acronyme de Wireless Markup

Language) permettant aussi de structurer sémantiquement et de mettre en page le contenu des pages, d'inclure des ressources multimédias dont des images, des formulaires de saisie, et des applets, et de créer des documents interopérables avec des équipements très variés et de soutenir l'accessibilité du Web.

[0006] Le nombre croissant de terminaux et d'applications différentes permettant de décoder des documents nécessite des systèmes dynamiques de conversion de documents compatible avec ces terminaux et ces applications.

[0007]On connaît dans l'art antérieur les documents suivants :

- « Model -driven design of service -enabled web applications », dont les auteurs sont Marco BRAMBILLA, StefanoCERI, Piero

FRATERNALI, Roberto ACERBIS et Aldo BONGIO ;

- « YoLinux tutorial : Java Servlets, JSP, Jakarta-Tomcat, a Database, Apache and Linux » de Greg IPPOLITO, et

- « Multilingual Web Pages with ASP and XML », de Ken COX.

[0008]On connaît aussi dans l'art antérieur, le document WO2005/08518 décrivant un procédé de génération de documents au format XML en un document au format HTML à partir des fonctionnalités d'un fichier XSL comprenant des données de présentation afin de structurer les données comprises dans le document XML. Ainsi un document envoyé au navigateur d'un terminal mobile ou d'un ordinateur aura une présentation adaptée et compatible avec chacun de ces navigateurs.

Cependant, un tel procédé présente des inconvénients liés au fait que la réalisation d'un tel fichier XSL requiert une expérience approfondie pour les types de manipulation de documents et donc se limite à une catégorie restreinte d'utilisateurs, ce qui pose des problèmes de maintenance, d'optimisation en temps lors de la mise en œuvre de ce procédé.

EXPOSE DE L'INVENTION

[0009] La présente invention vise à résoudre le problème lié aux difficultés techniques rencontrées pour la mise en œuvre d'un procédé ou un système de configuration de documents de manière rapide et simple.

[0010] L'invention propose d'optimiser les performances des mécanismes de configuration de fichiers à partir d'un processus de filtrage particulier permettant d'adapter les caractéristiques d'un document de manière à le rendre rapidement décodable par tout type d'application.

[0011]Plus précisément, l'invention a pour objet un procédé de configuration de documents destiné à une application donnée comprenant une première étape de configuration par :

- filtrage d'un fichier de base comprenant au moins un élément de référence identifiable par au moins un filtre,

- localisation des zones du fichier de base par chaque élément de référence, - génération d'instructions de configuration dans un fichier dit de configuration à partir du contenu des zones localisées dans le fichier de base, et une deuxième étape de génération d'un document par :

- extraction de données d'une base de données, - création dudit document à partir de ces données,

- conversion de ce document par exécution des instructions de configuration de la première étape, et

- récupération du document configuré à transmettre à l'application donnée.

Selon des modes de réalisation particuliers:

- le procédé comprend une étape préalable de réception d'une requête provenant d'une application afin de générer à la volée le document configuré à transmettre.

[0012] Plus précisément, l'invention se rapporte également à un système de configuration de documents destiné à une application donnée de mise en œuvre du procédé comprenant :

- un composant de configuration comportant au moins un filtre d'identification d'au moins un élément de référence d'un fichier de base apte à générer des instructions de configuration dans un fichier dit de configuration, et - un outil de génération de documents comportant un serveur relié à une base de données, ledit serveur comprenant des moyens de traitement aptes à extraire des données de ladite base de données pour créer un document modifiable par un convertisseur lors de l'exécution des instructions de configuration du fichier de configuration pour générer un document configuré.

Selon des modes de réalisation particuliers: - le convertisseur est un compilateur ;

au moins un filtre est compris dans le convertisseur ;

les données se rapportent à des éléments choisis parmi du texte, de la vidéo, et de l'audio ;

le fichier basique est au format XML ;

- les éléments de référence correspondent à des balises XSLT et/ou XML

DSL ;

filtre est préconfiguré de façon à traiter un type d'élément de référence prédéfini ;

le document est au format XML ;

- le document modifié est au format choisi parmi XHTML, HTML, et PDF.

l'application est un navigateur Web.

BREVE DESCRIPTION DES FIGURES

[0013] D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent :

- la figure 1 , illustre un exemple de réalisation de l'invention, - la figure 2, définie un mode de réalisation selon l'invention, et

- la figure 3, illustre des contrôles de saisie avancés dans un mode de réalisation de l'invention.

[0014] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de référence identiques sur l'ensemble des figures.

[0015] Le système de configuration de documents représenté à la figure 1 comporte un composant de configuration 22 et un outil de génération de documents 23.

[0016] Le composant de configuration 22 comprend un équipement informatique interagissant avec un utilisateur d'applications informatique, pas nécessairement un développeur professionnel, de sorte à générer un fichier de base 4. Ce fichier de base 4 comprend des éléments de référence tels que des balises.

[0017] Cet équipement informatique comprend, dans ces moyens de mémoire, des bibliothèques de balises XML rangés dans un espace de noms regroupant en plus des variables, des fonctions, et des classes. Chacune des bibliothèques de balises XML correspond à du XML DSL (signifiant XML Domain Spécifie Language, la notion de DSL définissant un langage créé spécifiquement pour un domaine fonctionnel : mise en forme graphique, multilinguisme, etc).

[0018] L'utilisateur en interagissant avec son équipement informatique génère à partir d'un langage basique au moins un fichier de base 4 qui est ensuite archivé dans une base de données reliée à un serveur apte à mettre œuvre au moins un filtre 7,8,9.

[0019] Ce fichier de base 4 est transmis à un filtre 7, lors d'une étape 11.

[0020] Le filtre 7 va identifier dans des zones localisées du fichier de base 4 un type d'élément de référence qu'il est capable de traiter afin de générer des instructions de configuration qui vont être archivées dans un fichier 14.

[0021] à titre d'exemple, le contenu d'un fichier de base 4 réalisé en vue de créer un composant de traduction pour un site Internet, peut comporter les codes, en langage basique, suivants :

<span xml:lang="fr">La version française de mon contenu <span class="mav">avec des balises dedans !</spanx/span>

ou encore :

<span xml:lang="en">The english version of my content <span class="mav">with tags inside</spanx/span>

avec :

- <span xml:lang="fr"> (ou <span xml:lang="en">) se rapportant à un élément de référence (ou balise) comportant un attribut se rapportant à la langue « fr » pour français et « en » pour anglais ;

- <span class="mav"> qui se rapporte à un élément de référence.

- les deux éléments de référence </span> sont associés aux éléments <span xml:lang="fr"> et <span class="mav"> avec lesquelles ils délimitent le champ d'application des éléments <span xml:lang="fr"> (ou <span xml:lang="en">) et <span class="mav">.

Entre les couples d'éléments de référence <span xml:lang="fr"> (ou <span xml:lang="en">) avec </span>, et <span class="mav"> avec </span>, des chaînes de caractères, comprises dans ces couples d'éléments, constituent dans cet exemple le contenu du site Internet en deux langues différentes.

[0022] Le filtre 7 localise des zones dans ce fichier de base 4 à partir des éléments de référence <span xml:lang="fr"> (ou <span xml:lang="en">) avec </span>.

[0023] Le filtre effectue un traitement particulier de ces zones, et génère les instructions de configuration suivantes comprises dans un fichier 14 :

<span>La version française de mon contenu <span class="mav">avec des balises dedans !</spanx/span>

et,

<span>The english version of my content <span class="mav">with tags inside</spanx/span>

Dans ces instructions l'élément de référence <span xml:lang="fr"> (ou <span xml:lang="en">) est transformé en un élément <span> pouvant être traitée rapidement par un convertisseur tel qu'un compilateur.

[0024] On remarque que ces instructions comportent les chaînes de caractères correspondant aux parties française et anglaise du site Internet.

[0025] Par ailleurs, on peut noter que de manière classique, le support multilingue d'une page Web passe par des fichiers compilés, que seul un développeur peut générer alors que les traductions ne sont pas faites par des développeurs.

[0026] Un des avantages de l'invention est de permettre à un utilisateur n'ayant pas de connaissance approfondie dans les langages de programmation de pouvoir réaliser des composants informatiques à partir notamment du langage basique mise en œuvre dans l'invention.

[0027] Les balises XML comprises dans le fichier de base 4 ont été transformées en code XSLT. Ces codes XSLT sont une composante des instructions comprises

dans le fichier 14. Ce fichier 14 est ensuite transmis, lors d'une étape 13, à un serveur de traitement de données compris dans l'outil de génération 23.

[0028] Cet outil de génération 23 de documents comprend une base de données 3 comprenant différentes informations provenant de sources hétérogènes, le serveur de traitement de données 15 et un serveur LDAP (acronyme de Lightweight Directory Access Protocol, qui correspond à un protocole normalisé facilitant la recherche d'informations organisées en annuaire ou en répertoire) et un serveur Web pour des pages de la toile décrivant un produit ou un service.

[0029] Les informations comprises dans le serveur LDAP et la base de données correspondent par exemple à des données telles que du texte, des éléments audio et/ou vidéo, ou encore à des images.

[0030] La base de données 3 et le serveur LDAP sont reliés à un serveur de traitement comprenant un module permettant l'extraction de données.

[0031] Ce module d'extraction de données permet de collecter, normaliser et assembler les données hétérogènes stockées dans la base de données 3 et le serveur LDAP, afin de générer un document 1 au format XML, lors d'une étape 2.

[0032] De plus ce module a pour fonction de normaliser les données extraites en mettant en œuvre des algorithmes à tolérances de fautes développés de manière à restituer un document conforme aux prescriptions XML. Ce module comprend une unité d'analyse syntaxique SGML pour une analyse de tolérance de fautes des documents balisés, pour la mise aux normes XML, et pour l'arborescence du document résultant en tant que mode dynamique de représentation du contenu des données originelles.

[0033] Le format XML du document généré n'est pas limitatif, d'autres formats peuvent être générés par ce module d'extraction de données. On peut citer par exemple CSV, HTML 3.2 ou HTML 4.0, et autres formats de type texte.

[0034] Le document 1 est transmis par les moyens de traitement à un module de conversion 5, lors d'une étape 10.

[0035] Le serveur de traitement comprend dans ses moyens de mémoire un module de conversion 5 tel qu'un compilateur 5 permettant à partir des instructions comprises dans le fichier 14 reçu et du document 1 de générer un document configuré 6, lors d'une étape 12.

[0036] Ainsi, le fichier de base 4 contenant des balises XSLT et d'autres XML DSL est traité par plusieurs filtres successifs pour finalement générer un fichier 14. Ce fichier 14 est traité par le compilateur avec le document 1 afin d'obtenir un document configuré 6. Ces étapes permettent de faire en sorte que le fichier initial contienne des balises XML plus appropriées à chaque domaine fonctionnel et soit donc plus simple et intuitif à écrire sans que la transformation finale perde en performance voir gagner en performance grâce à l'étape de conversion 12.

[0037] Le compilateur correspond par exemple des modules de conversion basés sur des langages tels que MSXML, Xalan/Java, Xalan/C++, Saxon, ou encore tout autre moteur XSLT.

[0038] Le document configuré 14 peut être au format XML, XHTML, PDF, etc...

[0039] Un des avantages de l'invention est de s'affranchir de technique de programmation informatique qui crée l'illusion de base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé, tel que des ORM (acronyme de object-relational mapping, qui se traduit par correspondance entre monde objet et monde relationnel).

[0040] En effet, le codage de l'accès aux sources de données passe par du code compilé ou généré automatiquement par des ORM qui posent des problèmes de maintenance et d'optimisation. Il est aisé de réaliser une application, mais difficile de la maintenir et de l'optimiser par la suite et en particulier lors de montée en charge.

[0041] Dans l'invention, la compilation s'appuie sur une fonctionnalité standard des interpréteurs XSLT qui permet d'implémenter son propre chargeur de fichier XML

[0042] Dans un mode réalisation de l'invention, le serveur fournit après traitement un fichier XSL standard à un compilateur. Ce compilateur effectue, nativement, le traitement des éléments de référence compris dans le fichier de base.

[0043] à la figure 2, le serveur de traitement de données 15 comprend des moyens de traitement 17 comportant des moyens de mémoire 18 et un processeur 19. Ces moyens de traitement échanges des données avec des moyens de communication 20,21. Ces moyens de communication 20,21 sont reliés avec respectivement la base de données 3 et un équipement informatique 16 comprenant une application telle qu'un navigateur Web permettant de décoder le document configuré 6.

[0044] Ces moyens de traitements sont aptes à extraire des données de ladite base de données 3 pour créer un document 1 modifiable par un convertisseur 5 lors de l'exécution des instructions de configuration du fichier de configuration 14 pour générer un document configuré 6.

[0045] L'invention a des applications dans de nombreux domaines tels que :

- le commerce électronique,

- les applications métier en ligne (ERP, CRM...)

- la publication de document en ligne.

L'invention peut être utilisé en tant que :

- outil de conversion de page Web à destination de matériel,

- outil de conversion de document d'un format à un/des autre (s),

- outil multilinguisme pour la traduction à la volet de site Internet ou de documents,

- outil de contrôles graphiques, et

- outil de gestion des droits applicatifs.

[0046] L'invention peut être appliquée pour optimiser des sites Internet de contenu séparant les données dites « à vie longue » qui seraient précompilées avec des données dites « à vie courtes ». On entend par données à vie longue des données textuelles correspondant à des articles, des descriptions de produits. Les données à vie courte celles qui correspondent par exemple à des données éphémères comme celles d'achats de produit (par exemple le panier e- commerce).

[0047] Dans un exemple d'application, l'invention permet de développer et mettre en œuvre un composant informatique de gestion des commandes fournisseur dans le cadre du fonctionnement d'un ensemble de sites, de crèches dans cet exemple, au travers d'une interface Web consultable dans le réseau Intranet des crèches. Ce composant est intégré à l'interface Web existante.

[0048] Ce composant de gestion de commandes fournisseur respecte dans son utilisation les points suivants :

- gestion des droits avancée : l'interface Web avant l'intégration de ce composant permet à tout utilisateur d'accéder à tous les écrans soit pour une crèche précise soit pour toutes les crèches. Pour ce nouveau composant, on doit pouvoir restreindre l'accès à certains écrans suivant plusieurs profils. Par exemple, un employé de la crèche peut créer une commande, mais seul le responsable de la crèche peut la valider. Dans ce cadre la mise en œuvre d'un système de gestion de droits simple à administrer pour l'utilisateur et simple à intégrer dans le développement de l'interface graphique doit être réalisé par l'invention ;

- contrôles de saisie avancés : le processus de commande est accéléré par rapport aux commandes manuelles ; pour ce faire, choisir un article doit être une opération rapide, et ce parmi un grand nombre d'articles possibles. Pour cela, un contrôle graphique où l'on choisit un article en tapant le début de son nom devrait être possible. Dans ce cadre la mise en œuvre simple de ce contrôle dans les différents écrans doit être effectuée ;

- développement rapide : le composant doit être développé rapidement pour être intégré dans l'interface Web.

[0049] Concernant le premier point, la principale difficulté dans un système de gestion de droits est d'arriver à doser la granularité ; si les droits sont trop généraux (accès à tel ou tel écran), l'administrateur (ci-après nommé le client) du site Internet dans lequel est comprise l'interface Web existante ne peut pas définir les profils dont il a besoin. Si les droits sont trop précis (tous écrans, boutons, champs), le client abandonne la définition de ses profils et donne accès à tout. Or, quand on définit la bonne granularité pour le client, la gestion devient fastidieuse dans le cadre du développement ; le client peut ne souhaiter gérer l'accès qu'au niveau de l'écran, ou bien bouton par bouton.

[0050] Par conséquent, il convient de mettre en œuvre une gestion arborescente des droits, niveau par niveau : menu, écran, action. Si l'utilisateur a accès à l'écran sans restriction sur des actions présentes au niveau de l'écran, il y accède directement. Ainsi, quand le client veut définir un accès illimité à un écran, il peut le faire sans avoir à donner accès à toutes les actions ; s'il souhaite descendre au niveau action, il peut le faire.

[0051] Un droit peut alors se définir selon le code suivant :

menu.ecran. action,

avec :

- menu correspondant au menu général de l'application,

- écran à un écran spécifique du menu ou à un élément géré dans le menu, et

- action une action spécifique sur cet écran ou cet élément.

à titre d'exemple, le code commande. modificationcommande.mettreajour correspond au menu de gestion des commandes, écran de modification d'une commande, bouton de mise à jour d'une commande sur cet écran.

[0052] Reste à intégrer cette gestion de droits dans le codage de l'interface graphique. Pour cela, il est important de savoir si l'utilisateur bénéficie des droits nécessaires menu par menu, écran par écran, action par action. Lors de l'accès à un écran, il est possible de récupérer la liste de tous les droits de l'utilisateur et d'y accéder à la demande. Toutefois un problème peut se poser et résulter du volume de données importantes à extraire d'un coup, et aussi de la gestion des droits arborescents qui serait complexe à effectuer dans le cadre d'une interface graphique, en particulier pour un développeur-intégrateur.

[0053] La solution est de mettre à la disposition du développeur-intégrateur une fonction qui lui permet pour chacun des droits de déterminer si l'utilisateur a un droit d'accès ou pas, plutôt que d'extraire de manière fastidieuse de la liste des données brutes qui pourraient apporter la réponse au développeur-intégrateur.

[0054] Cette fonction correspond par exemple en langage C# au code suivant:

public bool HasAccessRight(string accessRight.string user).

En instanciant cette fonction avec le code suivant menu.ecran. action, défini précédemment, et en précisant à partir de l'élément "string user" le nom d'utilisateur on détermine si celui-ci a un droit d'accès ou pas à chaque menu, écran ou action.

Ainsi, le développeur intégrateur réaliserait dans un tel contexte le code suivant :

- exemple en langage C#, ASP.NET :

<script runat="server"> (se rapportant au début classique d'un bloc ASP.NET)

if(HasAccessRight( ^ll commande.modificationcommande.mettreajour",currentUser) { (test sur le droit d'accès)

[afficher le bouton permettant la mise à jour] (se rapportant àl'affichage du bouton)

}

</script>

- exemple en langage XSL :

<xsl:if test="accessright:HasAccessRight('commande.modificationcomma nde.mettreajour ',$currentUser)"> (se rapportant au test sur le droit d'accès de l'utilisateur)

<acs:Button id="createProduit" text="Créer un produit" action="go(1 ,311 ,", ¹¹ ,",");"/> (se rapportant à l'affichage du bouton)

</xsl:if>

[0055] On remarque que cette syntaxe est assez lourde, et peu pratique pour un développeur-intégrateur.

[0056] Dans le procédé selon l'invention, le développeur, dans l'optique de résoudre ce problème, réaliserait le code suivant en langage simplifié afin de créer le fichier de base 4 :

<acs:Button id="createProduit" text="Créer un produit" action^goO ^I WVW ¹ right:visible="'commande.modificationcommande.mettreajour"'Î »>

avec right:visible l'élément de référence.

Cet élément de référence se rapporte à l'affichage du bouton et à la gestion des droits.

[0057] Le fichier de base 4 contenant ce code est ensuite analysé par au moins un filtre qui détecte l'élément de référence « right:visible » et génère des instructions de configuration comprises dans un fichier 14. Il apparaît clairement en comparant les lignes de codes en langage C#, ASP.NET et XSL énoncées ci- dessus à l'alinéa 53 au code en langage simplifié selon l'invention à l'alinéa 55 que le développeur intégrateur gagne en lisibilité, simplicité, et en temps de développement.

[0058] De plus, une action peut être considérée comme n'ayant pas besoin d'être filtrée par un droit d'accès ; avec cette syntaxe, ajouter un droit d'accès ne nécessite que d'ajouter un simple attribut sur la zone d'interface graphique à filtrer.

[0059] En référence au deuxième point « contrôle de saisies avancées », la figure 3 décrit ces contrôles selon la fonctionnalité suivante :

- les éléments 32 sont ordonnés par le champ login 30 (entre parenthèses) ;

- le début du login est saisi dans le champ de recherche 31 en haut, et

- le contrôle sélectionne automatiquement la ligne la plus proche du texte saisi.

[0060] Par conséquent, il convient d'une part d'ordonner les éléments de la liste, et, d'autre part, du côté d'un équipement client ou d'un serveur de positionner le texte recherché dans la liste. On connaît dans l'art antérieur, des langages de programmation côté serveur permettant de trier des listes de chaînes de caractère suivant une langue déterminée (français, anglais, suédois, etc.).

[0061] Par contre du côté de l'équipement client, javascript (langage de programmation de scripts principalement utilisés pour les pages web interactives) est connu pour être un langage de choix, ne connaissant que la langue anglaise pour la comparaison de chaînes, car il ne supporte que la norme ASCII (acronyme

de American Standard Code for Information Interchange qui est la norme de codage de caractères en informatique).

[0062] Dès lors, le tri se fait du côté du serveur.

[0063] Pour obtenir une interface graphique rapide, la recherche doit être effectuée à chaque frappe. De ce fait, le serveur renvoie l'ordre de l'élément saisi par l'utilisateur, ou bien un élément qui permet de déterminer cet ordre en langage javascript. Si le serveur renvoie l'ordre, il doit maintenir en cache une liste de ce que l'utilisateur voit, ce qui d'une part est coûteux en ressources, et d'autre part compliqué à gérer puisqu'on ne sait pas côté serveur quand le client a terminé son travail (donc quand la liste en cache peut être relâchée). La solution est d'utiliser les fonctions standards renvoyant une chaîne hexadécimale constituant un tri pour une langue spécifique ; cette chaîne hexadécimale est triable en javascript puisque constituée uniquement de codes ASCII.

[0064] La solution complète nécessite donc :

- un champ de recherche ; quand l'utilisateur effectue une frappe clavier dans ce champ, le serveur doit être appelé ;

- un script serveur renvoyant la chaîne hexadécimale de tri ;

- la chaîne hexadécimale de tri pour chaque ligne de la liste de recherche.

Un script côté de l'équipement client pour rechercher la plus proche ligne en fonction de la chaîne renvoyée par le serveur.

[0065] Cette solution est la solution optimale, mais elle est complexe à mettre en œuvre, car elle fait appel à de nombreuses couches (génération du code HTML côté serveur, manipulation du code HTML côté client, appel AJAX (Asynchronous JavaScript And XML) de renvoi de la chaîne de tri).

[0066] Afin de simplifier cette solution, un nouveau contrôle graphique est créé en langage simplifié selon l'invention à partir du code, suivant :

<acs:ListChooser id= IiSt= id-expression= name-expression= init=>

Code affichant chaque ligne

</acs:l_istChooser>"/>

Avec, l'attribut "list" contenant une expression "XPath" donnant la liste des éléments parmi lesquels choisir, "id-expression" une expression XPath donnant un identifiant pour chaque ligne, et "name-expression" une expression XPath donnant le nom pour chaque ligne (à partir de laquelle est effectué le tri).

Le code d'affichage de chaque ligne obtenue est introduit entre ces deux éléments de référence.

Ce contrôle inclut toute la solution complexe décrite ci-dessus en quelques lignes, un gain de temps de développement et de déboguage considérable.

[0067] Le gain de temps est, dans ce cas, important entre l'utilisation de code XHTML composé de XSLT et l'utilisation de contrôle pré-compilés.

[0068] En outre, le système selon l'invention est capable de configurer à la volée un nombre illimité de documents. Sous réserve de la bande passante disponible et des capacités des ressources matérielles du serveur de traitement.

[0069] D'autre part, on observera que la configuration de documents dans son application industrielle ne nécessite pas l'apprentissage long d'un nouveau langage de programmation complexe.

[0070] Par ailleurs, la présente invention telle qu'elle est décrite constitue un choix optimal parmi une multiplicité d'approches conflictuelles, en proposant une technique de configuration de documents unique harmonisant les interactions entre un composant de configuration et un outil de génération document.

[0071] La présente invention n'est pas limitée aux exemples de réalisation décrits et illustrés, plusieurs filtres peuvent être utilisés successivement chaque filtre étant dédié à un élément de référence spécifique.