Discussion :

[ujoodha]

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

[Erwy]

Oui, mais il faudra tes infos pertinentes: text(), comment(), processing-instruction etc......

[luta]

oui c est possible
assez simplement même...
mais il faudra être plus précis que cela sur tes "spécifications"

[GrandFather]

assez simplement même...

Simplement, peut-être pas...

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.

[Erwy]

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.

Pas tout a fait d'accord avec toi (mais faudra que tu te decide à le tester )

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.

assez simplement même...

On voit que tu n'en as pas fait de generique, même ordonnée strictement (bcp plus facile), pour dire ça

[GrandFather]

Le problème se situe plutot au niveau de la generalité de la notion de différence.

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.

[Erwy]

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.

Teste l'algo, je ne sais plus trop ou je me suis arrêté ., par contre le pb c'est surtout


est ce que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<a>
a<!--test-->b
</a>
 
<a>
b<!--test-->a
</a>
 
<a>
ab
</a>

sont equivalent
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())

[GrandFather]

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.

[Erwy]

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 ?

[GrandFather]

Donc dans un "non-ordonné" toi tu prends pour principe que seul l'odre des fils element et attributs peut varier , c'est ça ?

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.

[Erwy]

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.

Tel quel pour moi il ya contradiction

tu me dis que

<r>
<a/>
<b/>
</r>

equivalent

<r>
<b/>
<a/>
</r>

mais que

<a>
a<!--test-->b
</a>

different de

<a>
b<!--test-->a
</a>

alors que

sans que les éléments aient un traitement différent des autres noeuds

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 contraintes

[GrandFather]

tu me dis que

Code :

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

1
2
3
4
<r>
<a/>
<b/>
</r>

equivalent

Code :

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

1
2
3
4
<r>
<b/>
<a/>
</r>

Ah non, j'ai jamais dit ça...
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>

[Erwy]

Ah non, j'ai jamais dit ça...

Donc on ne parle pas du tout de la même chose

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

<r>
<a>
<b>1</b>
<c>2</c>
</a>
<d>
<e>1</e>
<f>2</f>
</d>
</r>

equivalent à

<r>
<d>
<f>2</f>
<e>1</e>
</d>
<a>
<c>2</c>
<b>1</b>
</a>
</r>

ça c'est chaud

[GrandFather]

ça c'est chaud

C'est bien ce que je te disais !

[Erwy]

C'est bien ce que je te disais !

Chaud mais pas infaisable à condition de rester dans une réponse strictement vrai/faux (on ne considère pas le deplacement comme une modification)
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

[GrandFather]

Chaud mais pas infaisable à condition de rester dans une réponse strictement vrai/faux (on ne considère pas le deplacement comme une modification)

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.

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

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...

[Erwy]

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.

On parle enfin de la même chose
Par contre j'aurais tendance à penser que cet algorithme, une fois realisé , 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

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...

La on est enfin d'accord
pas evident mais peut être faisable, a voir

[Erwy]

Un petit essai (pour ceux qui veulent tester), mais je pense qu'il y a un truc qui manque du coté du count(*) 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é)

[GrandFather]

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.

[Erwy]

et à le faire pour des arbres ordonnés.

Donne moi ta definition d'arbre ordonnée avant