OVH Cloud OVH Cloud

Grep dans un XML ?

8 réponses
Avatar
Marc
Bonjour,

Je cherche a faire un grep un peu particulier dans un XML et je
m'emmele les pinceaux avec les notions d'arbre et de parsing mais
egalement en raison du nombre de modules qui existent...

J'ai cru comprendre en parcourant le net et les news, que XML::XPath,
XML::LibXML et XML::Twig etaient des modules relativement adaptes (en
termes de simplicite d'API et de performances) mais je ne sais pas
lequel utiliser. Au passage si quelqu'un connait un comparatif des
commandes des ces librairies ca pourrait me laisser entrevoir la
lumiere (au niveau complexite de chacun) ...

J'ai commence mon programme en utilisant XML::Simple et XML::XPath
(bonjour l'uniformite ...) mais pour les prochaines etapes je crois que
je vais avoir du mal avec ces deux la.

Bref, explicitons le cas c'est mieux.

Je peux avoir des "objets" definis comme suit dans mon XML.
<holder name="hSimple">
<of>
<object class="SIMPLE"/>
</of>
</holder>
<object class="SIMPLE" name="oSIMPLE"/>

Or je desire lister les noms (name) de ces objets (ou de leurs holders)
de classe SIMPLE puis chercher les occurences de ces noms dans
certaines sous-parties (blocs) de mon fichier XML. (i.e. compter les
occurrences de hSimple et oSIMPLE)

Pour lister les noms d'objets (ou holders) de SIMPLE, j'ai essaye
d'utiliser les commandes xpath->find, avec get_nodelist et
get_nodevalue mais ca marche pas:

my @nodelist =
$xpath->find("//object[\@class=SIMPLE]/\@name")->get_nodelist();
foreach (@nodelist) {
printf( "- ".$_->getNodeValue()."\n" );
}

J'ai un resultat vide :-(
Dois-je proceder avec deux boucles distinctes puisque dans le cas du
holder, le nom se trouve a un niveau pere de l'objet ? De plus, je
connais le chemin exact de mes holders et objets, existe-t-il une
commande plus rapide que $xpath->find pour lister leurs noms ?

Concernant la zone de recherche, certains blocs peuvent etre definis
ainsi:
<function name="f1">
<block><![CDATA[
begin
// printf(oSIMPLE->intMyInt1 + 1);
//junk gavgdwvckgcvkwvckjwfckwfvcsv
printf(oSIMPLE->intMyInt1);
end;
]]></block>
</function>

Evidemment, je cherche a restreindre mon grep afin de reduire le temps
d'exec sur des fichiers pouvant atteindre plusieurs megas. J'ai donc
pense recuperer dans une liste les lignes des <block> pour ensuite les
parcourir et compter les nombre d'occurences de chaque objets recupere
plus haut. Mais je sais pas recuperer le bloc dans ma liste ...

En resume:
Comment compter les occurrences de hSimple et oSIMPLE dans les blocs de
mes fonctions comme f1 ?

J'ai l'impression que ce cas mele arbres et parsing...

D'avance merci pour quelconque aide et desole de la longueur du message.

8 réponses

Avatar
Michel Rodriguez
Marc wrote:

J'ai cru comprendre en parcourant le net et les news, que XML::XPath,
XML::LibXML et XML::Twig etaient des modules relativement adaptes (en
termes de simplicite d'API et de performances) mais je ne sais pas
lequel utiliser. Au passage si quelqu'un connait un comparatif des
commandes des ces librairies ca pourrait me laisser entrevoir la
lumiere (au niveau complexite de chacun) ...


Salut,

Je n'ai pas trop le temps de regarder ton probleme en detail
aujourd'hui, mais tu peux jeter un oeil a:

xml_grep, installe avc XML::Twig, la doc est a
http://www.xmltwig.com/xmltwig/tools/xml_grep/xml_grep.html

xml_grep2, base lui XML::LibXML: http://www.xmltwig.com/tool/index.html

Ways to Rome qui te donnera des examples d'utilisation des differents
modules: http://www.xmltwig.com/article/index_wtr.html

En gros XML::LibXML est rapide et efficace. Il implemente bon nombre de
standards (XPath, DOM, XInclude je crois...) tres proprement. Je ne lui
voie que 2 desavantages: il est parfois instable, il vaut mieux s'en
tenir a une combinaison XML::LibXML - libxml2 qui marche, sans chercher
a upgrader libxml2, et utiliser le DOM pour travailler sur du XML n'est
pas forcement tres agreable. XML::Twig de son cote marche assez bien, il
est plus "perlien" que XML::LibXML, il est base sur expat et pas sur
libxml2. XML::XPath a mon avis est a laisser de cote. Il n'est plus du
tout supporte, et XML::LibXML le remplace sans probleme.

--
mirod

Avatar
Marc
Salut,

Donc, XML::XPath et XML::Simple sont a oublier et il est preferable de
passer a XML::LibXML ou XML::Twig.

Je vais decortiquer xml_grep et xml_grep2 pour comparer les complexites
mais il apparait sur les benchmarks des articles WTR que XML::LibXML
est plus rapide mais consomme parfois plus de memoire.

XML::LibXML sera sans doute la premiere solution que je vais essayer.

Par contre, je n'ai pas bien saisi le passage :
[...] il est parfois instable, il vaut mieux s'en tenir a une combinaison
XML::LibXML - libxml2 qui marche, sans chercher a upgrader libxml2,



Peux-tu preciser dans quels cas XML::LibXML est parfois instable et
expliquer cette notion de combinaison XML::LibXML - libxml2 ?

En parcourant les infos sur XML::Twig, il semble possible de "supprimer
de la memoire" les parties/blocs XML qui ne nous interressent pas.
Est-ce egalement possible avec XML::LibXML ?

En tous cas cela ressemble tres fortement a que je cherche a faire
lorsque je prevois de limiter mon grep a certains blocs definis de mon
XML. Isn't it ?

Encore merci.

MA

PS: Le lien vers le fichier tar.gz de la Latest version sur la page
http://www.xmltwig.com/xmltwig/index.html semble errone, il renvoi sur
le fichiers source de la 3.16 (mais le lien vers 3.17 des archives est
valide)

Avatar
Paul Gaborit
À (at) 22 Jun 2005 20:47:59 -0700,
"Marc" écrivait (wrote):
Peux-tu preciser dans quels cas XML::LibXML est parfois instable et
expliquer cette notion de combinaison XML::LibXML - libxml2 ?


Pour la combinaison :
- XML::LibXML est en fait un frontal de libxml2.
- libxml2 est la bibliothèque XML intégrée à GNOME (mais elle marche très
bien sans ;-).

Pour l'instabilité, je laisse Michel répondre car, de mon côté, je n'ai jamais
eu de problème avec XML::LibXML (et libxml2). Les instabilités (rares) que
j'ai constatées étaient putôt liées à XML::LibXSLT (et libxslt qui est la
couche XSLT qui vient par dessus libxml2). Mais il est vrai que mon usage de
ces deux modules (et donc de ces deux bibliothèques) n'est pas très intensif.


--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Avatar
Jérémy JUST
On Thu, 23 Jun 2005 09:48:38 +0200
Paul Gaborit wrote:

Pour l'instabilité, je laisse Michel répondre car, de mon côté, je
n'ai jamais eu de problème avec XML::LibXML (et libxml2).


Moi, j'ai surtout remarqué que la libxml (la bibliothèque en C ou
C++) avait une portabilité d'une médiocrité rare.

Certaines versions ne compilent pas sous Solaris 8. Aucune ne compile
avec le compilateur de Sun (du moins parmi celles que j'ai testées).
Pour le 64 bits, je crois que j'avais aussi rencontré des problèmes.
Tiens, pour rire, je vais essayer sous Linux/x86 avec le compilateur
Intel.



Puisqu'on en est à parler de modules pour XML en Perl, je serais
intéressé par vos avis sur un choix de modules:
Dans le cadre d'un cours de Perl, nous présentions XML::Simple,
XML::DOM et XML::SAX::Base, mais j'ai l'impression que ces modules ne
sont plus les plus utilisés (et XML::SAX::Base est trop compliqué).

Nous avons 1 à 2 heures à consacrer à XML, sachant qu'à ce stade du
cours, les élèves viennent de découvrir les notions de référence, de
module et d'objet. Ils ne savent généralement pas trop ce qu'est XML,
mais il leur arrive de manipuler des logiciels qui sont capables de
sortir leurs résultats sous un format XML.
Il s'agit surtout de les sensibiliser aux modules XML, pour qu'ils
sachent où aller quand ils en auront besoin. Accessoirement, ça fait
partie des applications « de haut niveau » qui concluent une semaine de
cours, en leur montrant qu'on peut utiliser des objets très simplement,
sans se soucier de leur implémentation.

J'aime bien XML::Simple car, bien que je ne lui voie pas trop
d'intérêt réel, il montre une belle structure de hash de hash de hash de
hash (ad lib).
Quels autres modules pourraient être présentés succinctement?



X-post: fr.comp.text.xml


--
Jérémy JUST

Avatar
mirod
Jérémy JUST wrote:
On Thu, 23 Jun 2005 09:48:38 +0200
Paul Gaborit wrote:

Pour l'instabilité, je laisse Michel répondre car, de mon côté, je
n'ai jamais eu de problème avec XML::LibXML (et libxml2).


Moi, j'ai surtout remarqué que la libxml (la bibliothèque en C ou
C++) avait une portabilité d'une médiocrité rare.


J'ai plutot eu des problemes d'incompatibilites entre des versions de
XML::LibXML et de libxml2. En general sous linux je tiens mes packages
(RPM)
a jour sans me poser de questions, et du coup il m'est arrive de faire
un
upgrade de libxml2 qui casse la compatibilite avec meme la derniere
version
de XML::LibXML. Pour etre honnete, dans la mesure ou le rythme de
developpement de libxml2 a ralenti, ca devrait arriver de moins en
moins.

Puisqu'on en est à parler de modules pour XML en Perl, je serais
intéressé par vos avis sur un choix de modules:
Dans le cadre d'un cours de Perl, nous présentions XML::Simple,
XML::DOM et XML::SAX::Base, mais j'ai l'impression que ces modules ne
sont plus les plus utilisés (et XML::SAX::Base est trop compliqué).


XML::Simple est bien adapte pour un certain genre de XML. Tout ce qui
est donne'es, sans contenu mixte. Un coup de XMLin, puis un petit
Data::Dumper ou YAML pour voir la structure de donnees chargee,
eventuellement
suivi d'un petit ajustement des options de XMLin, et voila, on ne
s'occupe plus
du XML. Ceci dit c'est vrai que ca n'est pas du tout objet comme
approche (ce
qui n'est pas un reproche pour moi ;--)

XML::DOM est a mon avis a proscrire. Il est vieux et plus vraiment
maintenu,
et surtout le DOM sans XPath est vraiment penible. XML::XPath est
largement
compatible avec XML::DOM, mais en plus il offre XPath. Ceci dit il est
a peine
moins vieux que XML::DOM, et plus maintenu non plus. Ah oui, j'ai
failli
oublier! XML::DOM::XPath, comme son nom l'indique, rajoute XPath a
XML::DOM.

Vraiment pour faire propre et conforme au standards il vaut mieux
utiliser
XML::LibXML.

Dans le monde XML::SAX, XML::SAX::Machines permet d'enchainer des
filtres SAX
(crees avec XML::SAX::*), et est assez elegant.

XML::Filter::Dispatcher semble pas mal aussi. Je l'ai peu utilise, mais

l'approche ressemble a XML::Twig, en plus rigoureux (donc plus chiant a
utiliser en pratique ;--)

Ce qui me conduit naturellement a: XML::Twig est a mon sens dans le
meme esprit
que XML::Simple: peut etre pas super elegant et les puristes peuvent y
trouver redire, mais au bout du compte ca marche et ca permet de faire
du vrai code
rapidement. Pas forcement a montrer dans les ecoles donc ;--(


Quels autres modules pourraient être présentés succinctement?


Sinon, comme d'hab', la FAQ a tous les links qui vont bieng:
http://perl-xml.sourceforge.net/faq/

--
mirod


Avatar
drkm
Jérémy JUST writes:

On Thu, 23 Jun 2005 09:48:38 +0200
Paul Gaborit wrote:

Moi, j'ai surtout remarqué que la libxml (la bibliothèque en C ou
C++)


En C.

avait une portabilité d'une médiocrité rare.


Si c'est le cas, il faut prévenir Daniel Veillard. Parceque
selon lui, c'est le contraire :

Libxml2 is known to be very portable, the library should
build and work without serious troubles on a variety of
systems (Linux, Unix, Windows, CygWin, MacOS, MacOS X, RISC
Os, OS/2, VMS, QNX, MVS, ...)

Quels problèmes as-tu rencontrés ?

--drkm

Avatar
Jérémy JUST
On 25 Jun 2005 20:56:18 -0700
"mirod" wrote:

XML::DOM est a mon avis a proscrire....


Merci pour ton avis bien détaillé et justifié! J'irai voir les modules
dont tu parles, et je choisirai ceux qui me semble les plus utiles aux
élèves.



Sinon, comme d'hab', la FAQ a tous les links qui vont bieng:
http://perl-xml.sourceforge.net/faq/


Je n'avais pas regardé s'il existait une FAQ là-dessus. Honteux je
suis!


Encore merci pour ton éclairage.

--
Jérémy JUST

Avatar
Jérémy JUST
On Sun, 26 Jun 2005 15:20:37 +0200
drkm wrote:

Moi, j'ai surtout remarqué que la libxml avait une portabilité
d'une médiocrité rare.
Si c'est le cas, il faut prévenir Daniel Veillard. Parceque

selon lui, c'est le contraire


J'en ai causé avec l'ingénieur système, qui est plus ordonné que moi
(il garde les logs de ses compilations/installations).
Les versions anciennes (celles d'il y a deux ans et plus) posaient
problème, mais ça semble réglé.


Maintenant, il reste un problème mineur (version 2.6.8): le Make de
Sun n'est pas entièrement supporté, et il a fallu utiliser le GNU Make
pour faire le « make check ».


--
Jérémy JUST