Ordre des attributs dans un élément

Bonjour à tous,

Comme vous le savez, l'ordre des attributs n'a aucune importance dans un élément. Les deux éléments suivant sont tous les deux valides avec la même grammaire:

Code:

---

1 2	<Tax rate="7.0" currency="USD">27.57</Tax> <Tax currency="USD" rate="7.0">27.57</Tax>

---

Dans mon cas, l'ordre des attributs est primordial. Après que mon fichier XML soit généré, j'applique un mécanisme de signature pour signer mon document afin d'éviter qu'une personne le modifie.

La version précédente de mon application utilisait DOM level1 avec JaxB. Dans la nouvelle version, nous avons fait évolué le tout: DOM level 2, JaxB 2.1.6. Le problème, c'est qu'avant, DOM me générait ceci:

Code:

---

<Tax rate="7.0" currency="USD">27.57</Tax>

---

et que maintenant, il inverse les attributs (apparemment pour les mettre par ordre alphabétique - du moins pour ce que j'ai pu constater):

Code:

---

<Tax currency="USD" rate="7.0">27.57</Tax>

---

Et bien entendu, la signature n'est pas la même pour les deux documents. Ce qui fait que mon application n'est plus capable de lire les fichiers xml créer par la version précédente. Elle me dit, à juste titre, que la signature n'est pas valide.

D'où ma question (finalement :roll:), comment faire pour obliger DOM à utiliser les attributs dans un certain ordre, et pas d'après son bon vouloir?

Merci de m'avoir lu, et également pour vos réponses.

Finalement, j'ai trouvé une solution relativement simple: je ne travaille plus avec DOM.

Pour être plus précis, lors de l'encryption, je ne fais plus qu'une transformation DOM, puis j'applique les mécanismes de cryptage. Et lors de la désencryption, je parse le fichier en String, au lieu de le transformer en DOM.

Voilà... :D un problème de moins!

Bonjour Mischka,

Tu as trouve une solution aton probleme donc je ne pense pas que tu sois interesse par mon post mais peut etre que ca pourrait t'intersser si tu voudrais revenir a une solution DOM.

Si les performances de lecture du DOM sont importantes, oubli mon post.

En effet selon les spec w3c l'order des attributs, les esapces entre attributs ne sont pas consideres en tant que Node. Donc apres serailization d'un DOM, toutes ces infos sont perduez.

Dans mon projet Akrogen , j'ai gere la possibilite de modifier un DOM tout en conservant l'ordre des attributs, les indentations, les esapces (entre attributs, elements) car Akrogen permet de modifier un XML en conservant les espaces, l'order des attributs...

J'ai gere ceci en developpant mon propre parser XML (qui n'est cepandant pas super performant) mais qui permet de garder toutes ces infos. Pour des fichiers de configs les performances sont largement sufiisantes.

Si tu es interesses, je pourrais t'envoyer les sources de mon parser XML.

Angelo

Merci pour ta réponse des plus intéressante. Est-ce que je peux trouver le code source sur ta page SourceForge?

Ok,

La version actuelle d'Akrogen contient le sjars qui gere le Parser XML que j'ai developpe, mais il y a un bug avec les CDATA que j'ai corrige dans mon autre projet TK-UI (qui sera integre a Akrogen).

Pour cela il faut que tu recuperes les 2 projet Eclipse :

org.akrogen.core et

org.akrogen.core.xml

Dans le projet *.core.xml, tu as un example dans la classe

DocumentWhitespaceBuilderTest

Voici son code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// Load test.xml into DOM DocumentWhitespaceBuilder builder = new DocumentWhitespaceBuilder(); Document document = builder.parse(DocumentWhitespaceBuilderTest.class .getResourceAsStream("test.xml"));   // Insert Element Element newElement = document.createElement("NEW_ELEMENT"); document.getDocumentElement().appendChild(newElement);   // Serialize it StringWriter writer = new StringWriter(); XMLWhitespaceSerializer serializer = new XMLWhitespaceSerializer(); serializer.serialize(document, writer);   System.out.println(writer.getBuffer().toString());

---

Cet example charge le XML suivant dans un DOM (qui au passage uen DTD qui n'existe pas (ca aussi le parser XML le gere):

Code:

---

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 36 37 38 39 40 41 42 43 44

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts PUBLIC "-UNKNOWN EN" "unknow.dtd"> <root name="...." id="..." > <toto v="A" id="e" />   <toto v="e" id="e" >   <![CDATA[ v,kfvnfjvnfj <a>     </a> ]]> </toto> <!-- xsnxsns         -->       <titi />   <titi>   <a>   </a>   </titi>           <test/> </root>

---

Cet example ajoute l'element NEW_ELEMENT a la fin du XML, et apres serialisation on a :

Code:

---

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 36 37 38 39 40 41 42 43

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root PUBLIC "-UNKNOWN EN" "unknow.dtd"> <root name="...." id="..." > <toto v="A" id="e" />   <toto v="e" id="e" >   <![CDATA[ v,kfvnfjvnfj <a>     </a> ]]> </toto> <!-- xsnxsns         -->       <titi />   <titi>   <a>   </a>   </titi>           <test/> <NEW_ELEMENT/></root>

---

Comme tu peux le remarquer, les indentations, order des attribust sont respectes (sauf pour la declaration de la DTD).

Mon parser XML est base sur Xerces, mais je pense qu'il est possible (ca fait longtemps que je l'ai coder) de pouvoir gerer n'importe quel type de DOM.

Je n'ai pas fait vraiment de distribution car je n'ai pas trouve actuellement de personnes interesses par mon Parser. Mais si tu es interesses, je pourrai sfaire une distribution et faire un trus plus propre avec des factory et tenter d'enlever la dependance avec Xerces.

J'espere que tu seras interesses, et n'hesites surtout pas a me faire des commentaires ou me remonter si il y ades bugs (j'ai tente de le tester a fond, et ca fait depuis un an que le parser XML tourne sur Akrogen sans de retour de bug (mis a part avec les CDATA).

Angelo