Passer au contenu

3. Exploiter des données stockéesXQuery et XPath faciliteront l’accès à l’information

Selon que l’on veut interroger, créer, insérer ou extraire de l’information dans une base XML, les outils ne sont pas forcément les mêmes. La solution implique souvent l’utilisation d’un parser.

Extraire, insérer ou interroger des informations en XML suppose une maîtrise de la structure du document afin de comprendre le vocabulaire et la syntaxe utilisés, et de pouvoir l’exploiter en conséquence. La plupart des éditeurs de bases de données proposent des outils de développement adaptés à cette particularité, outils que l’on retrouve également chez WebGain avec TopLink ou Ilog avec JRules. Deux approches coexistent qui utilisent les interpréteurs ou les langages de requête, mais elles ne sont pas concurrentes, les interpréteurs étant les seuls à permettre la création de documents. Ils sont utilisés pour les interrogations uniquement parce que les langages de requête propres à XML ne sont pas encore finalisés.

Des parsers efficaces, mais qui ralentissent les traitements

La plupart des bases de données, relationnelles ou natives XML, sont dotées d’analyseurs syntaxiques, également appelés interpréteurs (parsers). Accessibles à l’aide d’interfaces de programmation par des composants Java (servlets), en Perl, C et C++, voire en PL/SQL pour IBM, ils analysent la structure du document. Grâce à ces interpréteurs, il est donc possible d’effectuer une recherche dans des informations stockées en XML, d’extraire des données qui iront “remplir” le composant Java, par exemple, et ensuite d’alimenter l’application qui a effectué la requête. L’inverse est également vrai : les données saisies par un utilisateur dans un navigateur, par exemple, seront “portées” par le composant Java qui appellera le parser avant d’insérer les modifications dans les documents.Il existe deux principales catégories d’interpréteurs : DOM (Document Object Model) et SAX (Simple API for XML). Les premiers sont capables de lire et d’écrire dans un document XML tandis que les seconds sont limités à la lecture. Autre différence importante, qui a des répercussions directes sur les temps de réponse et les ressources nécessaires à l’exécution d’une requête : un interpréteur DOM lit l’intégralité du document avant d’effectuer une opération, là où SAX fonctionne de manière séquentielle. Dans tous les cas de figure, interpréter un document avant de l’interroger, quelle que soit la méthode, ralentit forcément le fonctionnement de l’application qui attend sa réponse, qu’il s’agisse d’un navigateur web, d’un serveur d’intégration B-to-B, etc.C’est la raison pour laquelle les éditeurs, soutenus par le W3C, travaillent à l’élaboration de langages de requête propres à XML qui permettraient d’extraire des informations des documents XML d’une façon assez semblable à celle de SQL. Après de nombreuses initiatives concurrentes, deux normes complémentaires semblent se dégager. La première, XPath, est ratifiée et implémentée par de nombreux éditeurs, et la seconde, XQuery, est en cours de définition.Mais l’utilisation d’un moteur XPath ou d’un moteur XQuery suppose que ce dernier connaisse la structure du document XML, soit sa DTD ou son schéma. Les spécifications de XML schéma n’ayant été définitivement ratifiées qu’en mai dernier, aucun éditeur de solution de stockage en XML n’a encore implémenté cette norme, pourtant indispensable pour atteindre le niveau de finesse des requêtes SQL avec XQuery, et surtout faciliter les échanges électroniques dans le cadre du B-to-B.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Marie Varandat