Version imprimable
Bonjour,
Je savoir comment on fait pour comparer la structure de deux fichiers xml.
Par exemple: si mon fichier A comporte 5 balise et mon fichier B comporte les meme balise mais pas organise de la meme maniere ou dans le meme ordre est il possible de faire un xsl qui serait capable de dire que mes fichiers sont identique malgre l'ordre d'affichage des éléments.
Merci
Oui, mais il faudra tes infos pertinentes: text(), comment(), processing-instruction etc......
oui c est possible
assez simplement même...
mais il faudra être plus précis que cela sur tes "spécifications"
Simplement, peut-être pas... :roll:Citation:
Envoyé par luta
La comparaison entre deux noeuds étant récursive, ça se complique très rapidement, et c'est pire s'il faut détecter les déplacements de noeuds, au point qu'un algorithme générique n'est pas faisable avec XSLT.
Pour ton problème précis, s'il est suffisamment trivial ça reste envisageable mais il faudrait que tu donnes plus de précisions.
Pas tout a fait d'accord avec toi (mais faudra que tu te decide à le tester :lol: )Citation:
Envoyé par GrandFather
Le problème est plutot de mon point de vue de voir ce qui est ou non une modification:
Si seul l'ordre des attributs,noeuds elements peut changer ca va
Ca se complique si on n'a des noeuds commentaires ou si on peut avoir la même valeur textuelle dans un noeud mais pas le même nombre de noeud text
.Et considère-t-on qu'il est different s'il a les même noeud texte mais pas dans le même ordre .....
Le problème se situe plutot au niveau de la generalité de la notion de différence.
On voit que tu n'en as pas fait de generique, même ordonnée strictement (bcp plus facile), pour dire ça :roll:Citation:
Envoyé par luta
Si on raisonne en termes de comparaison de deux arbres, donc avec une comparaison de tous les noeuds indifféremment de leur type, franchement c'est assez coton... J'ai vu des algorithmes implémentés en Python et en Java, utilisant généralement DOM pour la représentation des arbres, et je vois mal une implémentation en XSLT.Citation:
Envoyé par Erwy
Teste l'algo, je ne sais plus trop ou je me suis arrêté ., par contre le pb c'est surtoutCitation:
Envoyé par GrandFather
est ce que
sont equivalentCode:
2
3
4
5
6
7
8
9
10
11
dans le 1 et le 2 seul l'ordonacement des noeud texte change
et le 1 et le 3 on meme valeur textuelle mais pas meme nombre de noeud (si on ne prend pas le comment() en compte ).
Pour moi , prendre TOUS les noeuds , n'est pas forcemment le plus complexe (regarde ici si tu supprime le comment())
Pour un algorithme générique, les 3 éléments sont différents, et il devrait signaler comme changement la permutation des deux noeuds textuels entre 1 et 2, et la suppression du commentaire entre 1 et 3.
Donc dans un "non-ordonné" toi tu prends pour principe que seul l'odre des fils element et attributs peut varier , c'est ça ?Citation:
Envoyé par GrandFather
Il y a deux types d'algorithmes, un premier qui ne relève que les ajouts/suppressions, et l'autre qui relève en plus les déplacements, de loin le plus complexe. En fait, le principe d'un algorithme générique est qu'il n'y a aucun pré-supposé sur les schémas à comparer, et que la comparaison se fait noeud par noeud, sans que les éléments aient un traitement différent des autres noeuds.Citation:
Envoyé par Erwy
Tel quel pour moi il ya contradictionCitation:
Envoyé par GrandFather
tu me dis que
equivalentCitation:
<r>
<a/>
<b/>
</r>
mais queCitation:
<r>
<b/>
<a/>
</r>
different deCitation:
<a>
a<!--test-->b
</a>
alors queCitation:
<a>
b<!--test-->a
</a>
ici aussi pourtant seul l'ordre change, donc on a bien un traitement different sur les noeud text et element puisqu'il ne supporte pas les même contraintesCitation:
sans que les éléments aient un traitement différent des autres noeuds
Ah non, j'ai jamais dit ça... ;)Citation:
Envoyé par Erwy
En toute rigueur, les deux arbres sont différents, un algo ne sachant pas détecter les déplacement de noeuds indiquera le "delta" de cette façon, pour l'élément <r> :
- Suppression d'un <a>
- Suppression d'un <b>
- Ajout d'un <b>
- Ajout d'un <a>
Tandis qu'un algo avec détection des déplacements de noeuds signalera uniquement :
- Déplacement de <a>
Donc on ne parle pas du tout de la même chose :lol:Citation:
Envoyé par GrandFather
1) moi je parle d'un algo avec pour seul reponse de base egal/pas egal
2) quand je dis "non-ordonné"
c'est quand
equivalent àCitation:
<r>
<a>
<b>1</b>
<c>2</c>
</a>
<d>
<e>1</e>
<f>2</f>
</d>
</r>
ça c'est chaud :?Citation:
<r>
<d>
<f>2</f>
<e>1</e>
</d>
<a>
<c>2</c>
<b>1</b>
</a>
</r>
C'est bien ce que je te disais ! :lol:Citation:
Envoyé par Erwy
Chaud mais pas infaisable à condition de rester dans une réponse strictement vrai/faux (on ne considère pas le deplacement comme une modification)Citation:
Envoyé par GrandFather
Par contre c'est la que reviens ma question
Considère tu ou non que l'inversion de noeud texte en est une ou non ?
Si oui , alors le traitement d'un noeud element est bien différent de celui d'un noeud texte
Mais je reste dans un contexte avec comme seule reponse vrai/faux
Les algorithmes dont je parlais génère un Delta, c'est à dire une liste (souvent en XML) des différences entre un fichier A et B. Si on compare A et B uniquement pour dire s'ils sont équivalents ou non, sans relever les différences, ça devient effectivement beaucoup plus gérable. ;)Citation:
Envoyé par Erwy
J'aurais tendance à dire que oui. L'inversion de 2 noeuds textes dans un élément à contenu mixte implique très certainement une modification de la sémantique, tandis qu'une inversion de deux éléments ne devrait pas avoir de répercussion sur les traitements en aval, à partir du moment où ils conservent le même parent bien sûr. Et si une inversion de deux éléments peut avoir des répercussions négatives, et qu'il faut s'en garantir, il suffit de faire une validation par schéma pour les repérer...Citation:
Envoyé par Erwy
On parle enfin de la même chose :mouarf:Citation:
Envoyé par GrandFather
Par contre j'aurais tendance à penser que cet algorithme, une fois realisé :mouarf: , peut être une bonne base pour le "Delta"
- soit par l'ajout de composant "xsl:script" pour donner le resultat que tu suggérais
- soit peut être par une "difference des deux fichiers" , mais qui demandera alors une plus grosse modif et de savoir exactement ce qu'on transfert
La on est enfin d'accord :mouarf:Citation:
Envoyé par GrandFather
pas evident :? mais peut être faisable, a voir ;)
Un petit essai (pour ceux qui veulent tester), mais je pense qu'il y a un truc qui manque du coté du count(*) :koi: peut être est compensé par le double appel , la procedure verifiant que A inclut dans B
je ne gère ni les namespace ni les PI (encore que celle la c'est plus pour garder l'algo comprehensible que par difficulté)
Ca a l'air de marcher pas mal du tout. :)
Peut-être serait-il intéressant de proposer la normalisation pour la comparaison des noeuds textes, afin de s'affranchir des problèmes d'indentation entre les deux fichiers.
Maintenant, il ne reste plus qu'à afficher en résultat les noeuds différents... et à le faire pour des arbres ordonnés. :mrgreen:
Donne moi ta definition d'arbre ordonnée avant :mouarf:Citation:
Envoyé par GrandFather