Discussion :

[italiasky]

Bonjour,

Je ne cherche pas à extraire la totalité d'un fichier XML.
C'est-à-dire que mon but est juste de pouvoir avoir une idée des balises présentes et avoir un exemple pour chaque balise.

Par exemple, si le fichier XML est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
<racine>
     <info>Liste de bouteilles</a>
     <bouteille>
          <type>eau</type>
          <marque>vittel</marque>
     </bouteille>
     <bouteille>
          <type>alcool</type>
          <marque>martini</marque>
     </bouteille>
     <bouteille>
          <type>eau</type>
          <marque>evian</marque>
     </bouteille>
</racine>

Au final, je cherche juste à pouvoir afficher la structure globale du fichier (les balises présentes) et un exemple pour chaque balise tout en gardant les niveaux d'imbrication :
racine
info (ex: liste de bouteilles)
bouteille
type (ex: eau)
marque (ex: vittel)

Mais voilà ça s'arrêterait là pour cet exemple, je n'ai pas besoin de plus de détail. Juste d'avoir un aperçu de ce qui se trouve dans le fichier XML.
C'est à dire finalement avoir la liste des balises avec un exemple de donnée pour que ce soit plus parlant pour comprendre la balise.

Je pourrais très bien utiliser n'importe quelle technique qui me retournerait le fichier XML en entier, etc mais par soucis de performance, je me dis que d'extraire tout le fichier XML dans ce cas la ne vaut pas le coup, n'est-ce pas ? Donc j'élimine de ce fait les solutions liées à DOM (xml.dom)

J'ai essayé ElementTree mais la totalité du fichier XML est aussi créé donc c'est pareil je dirai.

Du coup, peut être que SAX serait le mieux placer.. ?

Quelle technique me conseillez-vous parmi les différentes possibilités de manipulation de fichier XML fournies par python : http://wiki.python.org/moin/PythonXml

Voilà, j'aimerais juste vos conseils, savoir ce que vous feriez si vous aviez ce besoin sans utiliser une méthode "bourrin" qui en ferait beaucoup trop comparé au résultat recherché.

Merci
Michael

[plxpy]

Quelques réflexions :

1 - Certes, un module/package façon SAX te permet de ne pas tout décoder dans le détail ou même de sortir (break) du "parsing" si tu as trouvé ce que tu cherches, sans aller jusqu'au bout ou en sautant un élément déjà recontré. Façon DOM, tu charges et décodes tout ton fichier, dans tous les cas. C'est lorsque tu exploites l'arborescence que tu conserves tel ou tel élément pertinent.

2 - L'aperçu du fichier XML que tu veux n'est pas si évident que ça à obtenir, sauf si tu ne traites que des fichiers simples : là, il me semble que tu veux jouer sur le fait que, quand un élément de la racine a déjà été rencontré (ici <bouteille>), ce n'est pas la peine de traiter les suivants. Ca exclut donc ce genre de fichier (le tien à peine modifié), où apparait un élément optionnel (ici <volume>) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<racine>
     <info>Liste de bouteilles</a>
     <bouteille>
          <type>eau</type>
          <marque>vittel</marque>
     </bouteille>
     <bouteille>
          <type>alcool</type>
          <marque>martini</marque>
          <volume>0.75</volume>
     </bouteille>
     <bouteille>
          <type>eau</type>
          <marque>evian</marque>
     </bouteille>
</racine>

Et d'ailleurs, quel type de résumé souhaiterais-tu obtenir dans ce cas ?


Il me semble que si tu ne veux t'attaquer qu'à des fichiers XML simples, où chaque élément de premier niveau (juste en dessous de la racine) a toujours la même arborescence de sous-éléments, tu peux t'orienter vers une méthode "à la SAX" (ElementTree.iterparse peut faire l'affaire).

Si les fichiers ont une arborescence plus touffue mais surtout variable :

• avec une méthode SAX, tu vas devoir, quand même, balayer tout le fichier : tu ne décoderas pas tout (texte, attributs) mais au moins le chemin - succession des tags rencontrés - jusqu'à l'élément courant et tu devras savoir si tu as déjà rencontré ce chemin ou pas, pour l'afficher dans le résumé ou pas
• avec une méthode DOM, tu charges et décodes effectivement tout, mais j'ai l'impression que la "navigation" dans l'arborescence est quand même plus facile et conduit à un code moins "usine à gaz"

Bref, dans ce cas, les méthodes SAX ne me paraissent pas si intéressantes que ça (mais je peux me tromper).

[italiasky]

En effet ce n'est pas si simple car quand tu dis :
"quand un élément de la racine a déjà été rencontré (ici <bouteille>), ce n'est pas la peine de traiter les suivants. "
Ca dépend en fait de ce qu'on entend par "traiter" car pour reprendre l'exemple que tu as mis :
Voici ce que j'aimerais comme résumer après avoir analysé le fichier XML
racine
> info (ex: liste de bouteilles)
> bouteille
>> type (ex: eau)
>> marque (ex: vittel)
>> volume (ex:0.75)

Donc je cherche vraiment à lister toutes les balises.
Je veux connaitre toutes les balises possibles dans une balise de type "bouteille" par exemple. Du coup, lorsqu'on a traité le premier élément "bouteille", on devra quand même parcourir les autres éléments "bouteilles" jusqu'à la fin.

En résumé :
Si c'est un élément qui a des descendants, on descendra toujours voir ses enfants.
Si c'est un élément sans descendants : si c'est la première fois que ce type d'élément est découvert, on le sauvegarde avec sa valeur. Autrement on l'ignore et on continue.

Donc je dirai que je dois quand même parcourir tout le fichier et ne jamais sauter d'éléments si je veux être sur d'avoir un listing de toutes les balises présentes.
Je dois par contre stocker qu'une seule donnée par type de balise et il n'est donc pas nécessaire de décoder et charger en mémoire toutes les valeurs.

En fait, les fichiers XML devraient être assez simple mais par défaut je ne suis pas censé savoir à quoi ils ressemblereront.
J'aimerais justement pouvoir analyser n'importe quel fichier XML rapidement et afficher la structure globale pour savoir toutes les balises présentes, en gardant la cohérence au niveau des imbrications.

Je vais peut être m'orienter vers ElementTree.iterparse alors.
Et stocker dans une liste les éléments ?
Du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
["racine", 
             ("info", "liste de bouteilles"), 
             ["bouteille", ("type", "eau"), ("marque","vittel"), ("volume",0.75)] 
]

Ou ça fait usine à gaz et j'aurais du mal a parcourir ça par la suite....

Par contre, pour garder l'information de l'arborescence, je me demande si ca ne va pas etre compliqué parce que chaque élément renvoyé par iterparse ne contient pas cette info je crois...

Bref, je me demande si finalement manipuler un etree ne serait pas plus simple, tant pis si j'ai des valeurs qui ne servent à rien dans la mémoire.

Vous en dites quoi ?

Merci
Michael

[plxpy]

Comme je m'en doutais, il va donc falloir tout regarder et ne faire aucune impasse. L'apport d'une méthode SAX par rapport à une méthode DOM est uniquement le fait qu'on ne charge pas tout le fichier d'un coup.

J'ai un peu joué avec iterparse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
>>> from pprint import pprint as pp
>>> from xml.etree.ElementTree import iterparse
>>>
>>> def do_it(current,iterateur):
	sequence = [(current.tag,current.text.strip())]
	for event, elem in iterateur:
		if event == 'end' and elem.tag == current.tag:
			return sequence
		elif event == 'start':
			sequence.append((elem.tag,elem.text.strip()))
>>>
>>> iterateur = iterparse('bouteilles.xml',('start','end'))
>>> racine = False
>>>
>>> for event,elem in iterateur:
	if racine == False:
		racine = True
	elif event == 'start':
		sequence = do_it(elem,iterateur)
		print "nouvelle sequence :",
		pp(sequence)
 
 
nouvelle sequence :[('info', 'Liste de bouteilles')]
 nouvelle sequence :[('bouteille', ''), ('type', 'eau'), ('marque', 'vittel')]
 nouvelle sequence :[('bouteille', ''),
 ('type', 'alcool'),
 ('marque', 'martini'),
 ('volume', '0.75')]
 nouvelle sequence :[('bouteille', ''), ('type', 'eau'), ('marque', 'evian')]
>>>

Après, faut gérer les séquences trouvées, "fusionner" les séquences semblables, y mettre (peut-être) de la récursivité, ...

[pacificator]

Bonjour,

il n'y a pas de DTD fournie avec le xml?

[plxpy]

il n'y a pas de DTD fournie avec le xml?

C'est vrai qu'avec une DTD, ou mieux (?) un schéma XML, on serait guidé pour aller piocher les exemples de valeurs, sans y aller "à tâtons", avec l'obligation de tout parcourir.

Mais beaucoup de fichiers XML sont uniquement bien formés (un minimum !), sans indication particulière concernant leur structure.

Sans autre information, ce que cherche à écrire italiasky est un "schéma XML du pauvre". C'est juste une expression et pas du tout péjoratif : la fusion des différentes branches semblables n'est pas évidente du tout quand on veut être exhaustif (et les attributs n'ont pas été évoqués !)

Mais c'est vrai que c'est une bonne idée de se servir d'une DTD/d'un schéma.

[wiztricks]

Salut,

Techniquement, il serait préférable de deviner le XSD correspondant aux documents XML soumis.
1. Cela permet de tester "par ailleurs" que ce qui est produit est "correct,
2. Les constructions XML sont complexes. En passant par la grammaire XSD vous avez des "indicateurs" qui permettent de préciser les constructions "couvertes", des autres...
3. En passant par là, vous avez autre chose que les documents XML soumis pour construire votre code et le tester.
4. Un XSD est un document XML. La bibliothèque XML utilisée vous permet de le construire le modifier, le sérialiser,... Pas besoin de construire des structures de données Python "intermédiaires" pour faire le même boulot, in fine.

Cordialement,
- W
PS: Un document XML est "bien construit" lorsque conforme à son DTD ou à son XSD. S'il n'y a pas de DTD ou de XSD, ce n'est pas du XML mais du SGML, i.e. du texte avec des balises. Comme le CSV est du texte séparé par des ";". Faire le reverse engineering d'un schéma est contre productif: vous allez avoir à gérer un nombre indéfini d'exceptions qui sera fonction de la représentativité du XML donné en pâture au code...

[italiasky]

En effet, il n'y a pas de DTD, ni de XSD fournis!

Le terme de "schéma XML du pauvre" correspond tout à fait à ce que je cherche à faire, c'est-à-dire deviner la structure XML à partir d'un exemple.

@wiztricks : connais-tu un moyen de deviner facilement un XSD à partir d'un fichier XML ?

[italiasky]

Je viens de penser qu'un nom de balise peut aussi être utilisé plusieurs fois mais pas au même niveau:
Par exemple la balise info :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0" encoding="UTF-8"?>
<racine>
	<info>Liste de bouteilles</info>  <!-- ici -->
	<bouteille>
		<type>eau</type>
		<marque>vittel</marque>
		<dangereux>
			<info>oui</info>  <!-- ET ici -->
		</dangereux>
	</bouteille>
	<bouteille> 
		<type>alcool</type>
		<marque>martini</marque>
		<volume>0.75</volume>
	</bouteille>
	<bouteille> 
		<type>eau</type>
		<marque>evian</marque>
	</bouteille>
</racine>

Du coup, je me suis dis que c'est le chemin (le path) de la balise qui est le plus important car :
/racine/info
et
/racine/bouteille/dangereux/info
indiquent 2 balises différentes.
Si je me base que sur le nom de la balise (=info), je ne verrai pas la deuxième balise. Par contre avec le path, je ne peux pas en manquer une non ?

Qu'est-ce que vous pensez de cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
from xml.etree.ElementTree import iterparse
from xml.etree import ElementTree
 
def parse(usock):
    depth = 0
    path =""
 
    elements = []
    texts = []
 
    events = ['start','end']
 
    for (event, element) in ElementTree.iterparse(usock, events):
        if event == 'end':
            depth -= 1
            path = path[:path.rfind("/")]
 
        if event == 'start':
            depth += 1
            path += "/" + element.tag
            if path not in elements:
                elements.append(path)
                texts.append(element.text.strip())
 
    print elements, len(elements)
    print texts, len(texts)  
 
    for (index, item) in enumerate(elements):
        print "%s (ex:%s)" % (item, texts[index])
 
if __name__ == '__main__':
 
    usock = open("bouteilles.xml", "r")
    parse(usock)

Résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
['/racine', '/racine/info', '/racine/bouteille', '/racine/bouteille/type', '/racine/bouteille/marque', '/racine/bouteille/dangereux', '/racine/bouteille/dangereux/info', '/racine/bouteille/volume'] 8
['', 'Liste de bouteilles', '', 'eau', 'vittel', '', 'oui', '0.75'] 8
 
/racine (ex:)
/racine/info (ex:Liste de bouteilles)
/racine/bouteille (ex:)
/racine/bouteille/type (ex:eau)
/racine/bouteille/marque (ex:vittel)
/racine/bouteille/dangereux (ex:)
/racine/bouteille/dangereux/info (ex:oui)
/racine/bouteille/volume (ex:0.75)

[mont29]

À mon avis, vu comme c’est parti, tu te compliques les choses en utilisant sax… À moins que ton xml ne fasse plusieurs centaines de milliers de lignes, je pense qu’un PC moderne est parfaitement apte à le «*bouffer*» d’un seul coup (mode DOM).

Ensuite, je ne vois pas d’autre solution que de parcourir récursivement l’ensemble du doc, avec (par ex.) un dict pour y stocker ton «*schéma du pauvre*». Comme ça, à chaque nœuds, tu vérifies que tous les enfants (et éventuellement attributs) sont déjà dans le «*nœud*» correspondant du dict, et hop*!

En clair, pas d’autre solution que la méthode «*bourrin*», amha…

[shaiHulud]

Juste une remarque qui ne résoud rien. Si tu abandonnes les niveaux d'imbrication, une exploration ligne à ligne à la regexp te donnera les balises.
Si tu supposes que le xml est bien indenté, tu peux récupérer les imbrications de la même manière.

Du coup si on sait re-indenter automatiquement le xml de manière linéaire (?), c'est gagné.

[italiasky]

Merci à tous pour vos avis.

En effet il faut que je vois si j'abandonne ou pas la méthode SAX car les fichiers XML ne devraient pas être trop gros.

Par contre mont29, pour utiliser le dict, est-ce que tu penses a un dict "imbriqué", du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{"racine", {"info" : "Liste de bouteilles", "bouteille": { etc } } }

pour garder l'information sur les niveaux ?
Du coup, la recherche n'est pas très simple dans un dict de ce genre non ?

ou tu pense à un dict avec tous les noms de balises à plat, du genre :
{"racine" : "", "info": "Liste de bouteilles"}
ce qui ne me permettra pas d'avoir 2 balises avec un nom identique a un niveau différent. (ex: la balise info dans mon post précédent)

Quand je réfléchissais à utiliser un dict, je coinçais justement sur ce genre de questions, de savoir comment le structurer pour pouvoir le gérer facilement après.

A+

[plxpy]

Finalement, suite à tes derniers messages, je ne vois plus très bien où tu veux en arriver.

Si c'est un aperçu que tu veux, éventuellement pour des utilisateurs non-programmeurs (donc plutôt du visuel), des affichages un peu "chiadés" devraient faire l'affaire : tu indentes en fonction de la profondeur (le nombre de '/' dans tes tags) et c'est bon.

Mais là, apparemment, ton souci est de "naviguer" dans ton résultat.

Du coup, tu es en train de chercher une structure basée sur une combinaison de types de base Python (listes, tuples, dictionnaires) qui, si tu veux traiter une large gamme de fichiers XML, va plus ou moins bien marcher, avec telles ou telles limitations sur la structure du fichier XML traité.

Dans ce cas, pourquoi ne pas utiliser un type qui te tend les bras (xml.etree.ElementType ou un autre du même tonneau selon le package choisi), quitte, pour le côté aperçu, à reconstruire une arborescence simplifiée (1 seul élément <bouteille> mais avec tous les (sous) éléments comme <dangereux> et <volume>) ? C'était, je pense, le sens d'une des remarques de wiztricks "Pas besoin de construire des structures de données Python "intermédiaires" pour faire le même boulot, in fine."

[italiasky]

En effet, je crois bien que je me suis perdu en chemin
Très bonne remarque plxpy

Je ne sais pas pourquoi je suis resté scotché à l'idée de passer par une variable intermédiaire pour stocker mes éléments, et ensuite de traiter ce que j'ai stocké pour l'afficher.

Puisqu'au final c'est pour afficher dans une page html, j'ai qu'à générer directement le source html avec des <ul><li></li></ul> imbriqués pour les imbrications.

Je vais essayer de voir plutôt comme ça en effet. Merci

[italiasky]

Bonjour,

Je reviens vers vous après avoir avancé sur le sujet et découper et organiser mon code en package/module.
Je suis preneur de vos remarques, que ce soit sur le fond ou la forme.
En effet, ce sont mes premières lignes de code écrits en python donc n'hésitez pas à me donner des conseils sur la façon dont c'est codé mais aussi sur la présentation du code, les noms de modules/packages/fonctions/variables choisis, etc... j'essaye d'apprendre et de suivre les bonnes pratiques du monde python.

J'ai découvert une nouvelle contrainte lorsque j'ai testé avec un fichier xml quelconque : la présence de namespace. (ex: balise du type : <namespace:custo></namespace:custo>)
Je gère donc maintenant cela.

De plus, on avait évoqué plus haut de générer le html directement lors du parcours, ce n'est en fait pas possible car il se peut que je découvre une nouvelle balise enfant d'une balise X plus tard.
Le parcours de tout le fichier xml dans un premier temps est donc nécessaire pour découvrir toutes les balises possibles. Je parcours ensuite les données que j'ai conservées pour générer le html.

Pour information, je ne gère pas les attributs. Je n'en ai pas besoin pour le moment.

Voici le lien des sources : http://italiasky.alwaysdata.net/etl.zip
Le main se trouve dans etl.manage.py

Merci
Bon weekend!