Lecture des données XML

C’est une base de données au sens conceptuel du terme mais avec une structure pouvant être très versatile. Les données représentent une hiérarchie d’imbrications, et non des références entre entités, et peuvent être récursives. Qu’un document XML soit stocké dans une colonne XML ou de type texte à travers des VARCHAR ou des CLOB, il faut pouvoir en extraire sélectivement le contenu.  Généralement, une application n’utilise qu’un sous-ensemble de données réparti dans tout le document XML; elle agrège et traite une partie de ces informations. Il s’agit alors d’interroger un ou plusieurs documents XML pour extraire les parties signifiantes à l’application. Pour interpréter ce flux, les langages C/C++ et Java possèdent leur propre « parser » (SAX & DOM, JDOM) à travers les logiciels sous licence XML Toolkit et le JDK Toolkit, ou encore les projets open source Xerces & ANT d’« Apache Foundation ».

Avec l’arrivée de la V5R4, RPG bénéficie de « Parsers » natifs avec les nouveaux codes opération XML-INTO et XML-SAX. Le COBOL quant à lui possède cette possibilité de « parser » depuis la V5R3.  Mais il s’agit là de mécanismes de « bas niveau » et l’approche est plutôt programmatique, or la plupart des interrogations de données se font par un langage spécifique comme SQL qui lui, par contre, est conçu pour l’interrogation de données structurées.

Comment donc interroger un flux XML avec efficacité et rapidité ?

Il existe plusieurs méthodes (hors parseurs traditionnels cités plus haut) :

–    Le « Shredding » qui consiste à décomposer un document XML en une base de données relationnelle et ainsi permettre SQL d’en extraire le contenu (nous aborderons ce sujet dans le chapitre suivant)  avec de simples requêtes;

–    L’utilisation des extensions SQL tel xQuery de la norme SQL/XML ISO SQL :2003 soutenue par le W3C. Malheureusement cette extension n’a pas encore été implémentée dans DB2 en 7.1 ! mais une évolution logique des choses devrait nous permettre d’espérer  une future livraison de cette extension dans les toutes prochaines versions ;

–    La recherche grâce à d’autres outils standards, tel XSLT (eXtensible Stylesheet Language Transformation) proche de xQuery, qui sera lui aussi abordé dans le dernier chapitre de cet article;

–    La recherche « plain text » qui est différente d’une recherche d’occurrence de chaine de caractère tel un LIKE. L’opération de base d’une recherche « plain text » est le découpage  d’une chaîne afin d’en détecter les différents mots et d’indexer ces derniers. Cette recherche et indexation est possible avec l’extension gratuite « Omnifind Text Search for IBM i » livrée à partir de la V6R1 et de base en 7.1. Il s’agit d’une extension relative à la norme SQL :2003 « Full Text ». Elle permet l’utilisation de nouvelles expressions SQL  comme CONTAINS ou encore SCORE pour retrouver des données contenant certains mots ou formes fléchies de mots (grâce à de nombreux dictionnaires intégrés en fonction des langues utilisées), et éventuellement des synonymes dans les lignes des tables, y compris pour des colonnes de type LOB et XML. Mais « Omnifind Text Search for IBM i » ne s’arrête pas là, il supporte la syntaxe xPath afin de pouvoir faire des recherches sur un élément donné et/ou un attribut :

Exemple :

SELECT storeid, storezip FROM books
WHERE CONTAINS(storebooks, ‘@xpath:’
‘/bookstore/book[@price<15.00 or @genre= »autobiography »] » ‘)=1

Concernant l’approche programmatique, le nouveau type de donnée XML pourra être lu dans un programme HLL comme ses homologues LOBs à travers un LOCATOR. Il est aussi possible de régénérer un fichier dans l’IFS à partir d’une colonne XML comme montré en figure 6.

Un LOCATOR étant un pointeur, un ordre SELECT sur une colonne XML en 5250 renverra le résultat : *POINTER. Pour visualiser le contenu d’un champ XML il faudra utiliser d’autres interfaces telles ODBC/OLE DB ou encore JDBC, c’est le cas de iSeries Navigator (figure 7). Sinon, il faudra utiliser  la nouvelle fonction XMLSERIALIZE permettant de faire un casting d’un champ XML vers un CHAR/VARCHAR/LOB comme montré en figure 8 (Le CCSID du Job ne doit pas être 65535).

Il est important de rappeler que sans la présence de xQuery (en 7.1), il faudra utiliser « Omnifind Text Search for IBM i » afin de pouvoir faire des recherches pertinentes et rapides dans un flux XML en utilisant ses extensions xPath. C’est aussi le seul moyen d’indexer un document XML. Omnifind possède bien d’autres avantages, il permet notamment de faire des recherches à l’intérieurs de documents PDF, XLS, DOC etc… stockés dans une colonne BLOB. De plus, la gestion des index Omnifind est dorénavant intégrée à iSeries Navigator. Voir figure 9.