XML devient le standard pour décrire le contenu et les métadonnées associées au dit contenu. Son utilisation, aussi bien par les développeurs d’applications et de sites web que par les éditeurs de solutions de gestion de contenu ou de portails, pose la question du stockage des données XML. Si la plupart des constructeurs ont adapté leurs bases de données relationnelles à ces nouvelles données, des problèmes persistent. “Le schéma de la base de données peut ne pas être optimisé pour toutes les combinaisons possibles du contenu demandées par l’application. Et si elle l’est, cela peut avoir des conséquences involontaires sur la performance et sur les applications associées“, affirme le Yankee Group dans son rapport ” Native XML Databases Join Internet Application Infrastructure “.Quelques gros éditeurs, dont Software AG, ainsi qu’une myriade de start up se sont donc lancés dans les systèmes de gestion de bases de données (SGBD) nativement XML. A l’apparition de ces bases de données correspond également l’éclosion de nouveaux langages d’interrogation et de manipulation des contenus XML. Par une ironie du sort, ces nouveaux SGBD font faire un saut dans le passé. En effet, dans les premières bases, les données étaient classées selon un mode hiérarchique. Avec l’invention par Edgar Codd, en 1970, du concept de base de données relationnelle, apparaît SQL (Structured Query Language), le langage de manipulation et d’interrogation créé par IBM. Avec l’apparition de XML, le mouvement s’inverse, la structure de ce langage étant comparable à un arbre.SQL, conçu pour manipuler des données organisées en structures tabulaires, n’est pas adapté à la gestion des documents. Et XML n’est pas une réponse en soi. “Ce langage est un modèle de représentation de données ou de documents, et non un langage de requêtes “, résume Sophie Cluet, chef technique de Xyleme, une start up construisant un moteur de recherche pour les données XML. “Il vient avec un paquet de standards associés, comme XPath ?” pour retrouver un élément dans un document ?”, ou XSL ?” mise en page d’un document ?”, ou encore XQuery ?” interrogation d’un ensemble de documents “. C’est pourquoi de nombreux chercheurs ?” tant chez des éditeurs comme Software AG ou IBM qu’au sein d’organismes publics (Inria), coordonnés par le W3C ?” préparent XML Query, l’ensemble de spécifications destinées au futur langage de manipulation de données XML. Pour cela, les chercheurs ne partent pas de zéro. “Un compositeur médiocre emprunte ; un bon compositeur vole.” C’est en citant Stravinsky que se décrivent les chercheurs à l’origine de Quilt, un langage de requête XML destiné à des sources de données hétérogènes. Proposé en juin 2000 par Don Chamberlin, Jonathan Robie et Daniela Florescu, il s’inspire de XML-QL et de XQL. En 1999, XQL était pourtant considéré comme le standard. Interrogé par 01 Informatique, Phillip Merrick, le fondateur de Webmethods, disait alors : “XQL permettra d’exploiter pleinement la subtilité des objets en XML. ” Reste que le langage ne s’est pas révélé totalement satisfaisant. “Il ne permet pas de créer des éléments qui ne seraient pas dans le texte original ou de comparer deux documents“, constate Sophie Cluet. Et ce n’est pas fini. “Le groupe de travail du W3C a sélectionné Quilt comme point de départ pour développer XQuery “, affirme Don Chamberlin, chercheur au centre de recherche Almaden d’IBM à San Jose. Et d’ajouter : “Le langage a d’ores et déjà été modifié, e que d’autres changements seront opérés avant la publication des spécifications finales de Xquery.” XQuery n’étant lui-même qu’un sous-ensemble de XML Query, la norme de langage de requête XML sur laquelle travaille W3C.
La nécessaire synthèse conclut le foisonnement
XML Query s’inspire aussi de langages pour bases de données semi-structurées, tels que UnQL, et de systèmes de conversion de données comme YaTL (YAT Data Translation Language). Sans compter Xduce ?” ce langage de programmation est spécialisé dans le traitement de données XML (lecture, extraction et/ou conversion dans un autre format). Ou encore Lore, un système de gestion de bases de données XML créé par l’université de Stanford en 1995. Avant que les recommandations du W3C ne soient définitivement publiées, les éditeurs de contenu et de bases de données XML disposent d’un outil assez basique, XPath (XML Path Language). ” Path ” étant, dans le langage de l’administration de bases de données, le chemin entre un ensemble d’informations et un autre.Ce langage permet d’accéder à un ensemble de n?”uds d’un arbre XML, recherchés selon leur position, leur structure ou leur contenu. Il autorise également la manipulation de chaînes de caractères, de nombres en virgule flottante et de booléennes (vrai/faux). Reste que XPath est seulement un moyen de trouver des parties d’un document. Il ne dit rien sur la structure du document, contrairement à DOM (Document Object Model). De plus, “XPath ne permet pas, dans sa définition commune, de sélectionner plusieurs morceaux de documents plutôt qu’un seul “, explique Sophie Cluet.Cela n’empêche pas les éditeurs de bases de données XML, qu’ils utilisent XPath ou non, de vouloir migrer vers XML Query ou ses sous-ensembles. “Au sein de X-Hive/DB, il est possible de faire des requêtes XPath sur une collection de documents, indique Irsan Widarto, cofondateur et vice-président stratégie produit de X-Hive Corporation. Mais nous passerons à XML Query dès que le W3C fera une recommandation plus stable.“”Nous avons notre propre langage, avoue Tom Marvin, cofondateur et PDG par intérim de XYZFind. Mais cela est dû au fait que, il y a deux ans, il n’était pas évident que la syntaxe de requête allait devenir un standard.” La société est d’ores et déjà en train de faire les modifications nécessaires sur son produit pour le rendre compatible avec XQuery. Outre les recherches sur le langage d’interrogation, d’autres travaux sont en cours. Ainsi, le XML : DB ?” Initiative for XML Data- bases ?” planche sur la définition d’une API (Application Programming Interface) standard, qui permettra à des programmes n’utilisant pas XML de pouvoir agir sur les bases de données nativement XML.
Les SGBDR continueront à menacer les bases de données XML
Malgré toute cette agitation, l’avenir de ces dernières ne semble pas assuré. “La menace pour les bases XML reste la base de données relationnelle, explique Rob Perry, analyste au Yankee Group. Oracle est un gorille, et il continuera de pousser le SGBDR comme réponse à toutes les questions. Et il y parviendra dans la plupart des cas, de belle façon. ” Le marché de la gestion de données nativement XML, qui représentait déjà, selon IDC, un marché de 77 millions de dollars l’année dernière, pourrait bien exploser avec l’utilisation croissante de XML. A condition de ne pas sortir de sa spécialité.IDC le résume bien : les moteurs relationnels sont taillés pour les transactions, contrairement aux SGBD XML, utiles quand les données n’ont pas de schéma prédéfini ou qu’elles ont un schéma évolutif, ou encore quand le contenu est décrit en XML et qu’il n’y a aucun intérêt à le stocker dans une base relationnelle. Mais ce ne sera peut-être pas le critère de choix principal. “Le relationnel peut tout à fait répondre aux mêmes besoins, et avec les mêmes performances, affirme Jean-Christophe Bernadac, directeur technique chez Cosmosbay. Toutefois, la base de données nativement XML aura l’avantage du prix dans certaines configurations précises. “
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
