Comments on Comment travailler sur du XML en conservant le formatage ?

sbi (2017-03-02T22:31:41Z)

Ton approche en trois étapes decorate-treat-undecorate me fait penser à la
Schwartzian transform (et elle est très classique apparemment, d'influence
lispienne), qui me semble élégante et idiomatique mais avait fait hurler Tom
Christiansen à l'époque.

Alan (2014-12-04T07:02:13Z)

Après réflexion (vive les transports en commun), je ne pense pas qu'il soit nécessaire d'avoir un parseur en Boomerang, il suffit d'un parseur qui capture les informations que tu veux préserver (types de guillemets, espaces entre les attributs et les nœuds).

Alan (2014-12-04T06:04:01Z)

J'allais mentionner Boomerang, mais je vois que cela a déjà été fait. Juste une précision: "il gère le XML comme des arbres abstraits, pas pour sa syntaxe concrète". Mais tout (dont la syntaxe concrète) est un arbre abstrait. Si tu représente ton texte comme un flux de lexèmes, tu peux te retrouver dans le format de données supporter par Boomerang.

Le problème revient maintenant à écrire un analyseur lexical bidirectionnel. Et la question est: Boomerang étant un langage dédié, est-il assez puissant pour cela ?

Nick Mandatory (2014-11-13T13:27:30Z)

Je crois que ce qui me surprend le plus, c'est que le format que tu utilises quand tu écris du XML à la main ne soit pas formalisable :-)

Fabien (2014-11-13T09:55:52Z)

J'aurais tendance à injecter dans le texte original les modifications, plutôt que répertorier et regénérer toutes les variations syntaxiques.

Si text1 est l'original, xml1 le resultat de son parsing, xml2 le XML après modification, text2 la version texte de xml2 la plus semblable possible à text1:

* générer xml1 à partir de text1 (parsing) ; en plus du XML, il faut garder la correspondance entre chaque noeud et la position du texte qui le représente.
* générer xml2 à partir de xml1 (processing) ;
* chercher où xml1 diffère de xml2 ;
* générer les bouts de xml2 dont on ne retrouve pas l'original dans xml1 ;
* les assembler avec les fragments de text1 réutilisables.

Quelques limites prévisibles :

* ça ne sauvera pas l'indentation si des blocs changent de profondeur
* la notion de "noeud modifié" n'est pas complètement triviale, il faut une notion de "noeud identique à quelques fils près". Sinon l'heuristique s'arrête à "xml1 != xml2", et regénère tout…

Damien (2014-11-12T20:49:15Z)

La notion de lentille me fait aussi penser à Augeas ; il sait a priori travailler sur du XML mais je n'ai pas trouvé énormément de détails.
http://augeas.net/docs/lenses.html
https://twiki.cern.ch/twiki/bin/view/Main/TerjeAndersenAugeas

Ruxor (2014-11-12T14:49:34Z)

@Olivier: Ça ressemble effectivement à une théorie qui devrait couvrir ce que j'essaie de faire. Après, ce n'est pas clair du tout si l'outil Boomerang permet ou non ce que je cherche à faire concrètement sur du XML (j'ai plutôt l'impression que non — il gère le XML comme des arbres abstraits, pas pour sa syntaxe concrète), mais c'est intéressant de savoir que ça existe.

Olivier (2014-11-12T14:15:08Z)

Est-ce que tu connais les lentilles et le bidirectionnal programming ? Il y a un langage spécialement pour ça fait, fait chez Benjamin Pierce: <http://www.seas.upenn.edu/~harmony/>. Ça permet de faire des transformer des documents d'un format vers un autre, en laissant la possibilité de faire des modifications des deux cotés. Je ne sais pas trop dans quelle mesure ça gère les fichiers xml, et si ça n'a pas trop tendance à canonicaliser les documents produits.

Ruxor (2014-11-11T22:36:16Z)

@Damien: Merci pour cette suggestion. Il ne préserve pas tout, mais il préserve beaucoup plus que la plupart de ses concurrents — notamment, il préserve l'ordre des attributs et les entités (je parle de « xmlstarlet ed », parce que « xmlstarlet tr » fait autre chose). Du coup, en traitant d'une part mes fichiers par une transformation xmlstarlet qui ne fait rien, et d'autre part par la transformation qui fait ce que je veux, et en faisant le diff entre les deux, j'ai obtenu un patch suffisamment propre pour s'appliquer quasiment partout sur mes fichiers d'origine, et il n'y avait qu'un ou deux endroits à revoir à la main (et un seul où le patch s'était vraiment mal appliqué).

Damien (2014-11-11T21:20:37Z)

As-tu déjà utilisé xmlstarlet ? Il me semble (pas retesté) que lorsqu'il fait des modifs, il le fait le plus localement possible.
http://xmlstar.sourceforge.net/doc/UG/xmlstarlet-ug.html

Ruxor (2014-11-11T17:28:35Z)

@Vincent D.: Le souci avec le mot « constructif », c'est qu'on ne sait jamais bien ce que ça veut dire. Je voulais dire que la preuve exhibe explicitement une bijection (et ne fait pas appel, par exemple, à l'axiome du choix). Si par « constructif » on demande — ce qui est beaucoup plus fort — que le théorème soit vrai en mathématiques constructives à la Brouwer ou à la Bishop (et ne fait pas appel au tiers exclu), alors il ne l'est pas, comme expliqué dans <URL: http://mathoverflow.net/questions/123482/is-there-a-constructive-proof-of-cantor-bernstein-schroeder-theorem >. Mais si on est bien d'accord qu'on parle du sens faible (celui que j'entendais), c'est fait dans l'article Wikipédia vers lequel j'ai fait un lien (proof attributed to Julius König), ou dans son équivalent en français (il y a trois démonstrations, mais au moins la démonstration nº3 est simple et constructive, et identique à celle dans la Wikipédia en anglais). Ou dans à peu près n'importe quel livre de théorie des ensembles.

Vincent D. (2014-11-11T13:15:25Z)

le théorème de Cantor-Schröder-Bernstein peut être démontré constructivement ? Serait-il possible d'avoir une référence à lire ?

Ruxor (2014-11-11T10:37:09Z)

@davy: Le XML est dans un système de contrôle de version, donc certainement une raison est que je n'ai pas envie de faire un diff énorme (qui casserait « git blame » par exemple). Mais une raison encore plus importante est que ce XML est écrit à la main, que le formatage est choisi pour être ce qui m'arrange quand j'écris à la main, et qu'il n'est donc pas question d'y toucher. Par exemple, j'utilise un certain nombre d'entités pour écrire le XML de façon commode (par exemple, &my-email; est remplacée par la suite des balises qui représente mon adresse mail protégée contre le spam) ; de même, certains caractères sont en Unicode directement alors que d'autres sont représentés sous la forme &#xNNN; parce que c'est plus facile de les repérer comme ça ; et j'ai des sections CDATA que je veux garder telles quelles parce qu'elles servent à échapper du XML en le gardant lisible. Tout ça, c'est des méta-informations importantes qu'il faut absolument préserver.

davy (2014-11-11T02:38:55Z)

moi j'abonnerait l'idée que tu veux garder ton code à ta façon, et je metrai tout en canonique.

si le but est de versionner tout ça sans casser la comparabilité avec les version anciennes, j'ai l'impression que c'est quand meme plus facile d'écrire du code qui canonise les revisions avant de les passer dans diff.

menfin du coup ca répond pas du tout a ta question

Fred le marin (2014-11-10T19:31:26Z)

respectât (désolé d'avoir massacré ainsi la langue de Molière…)

Ruxor (2014-11-10T18:03:49Z)

@projetmbc: J'ai du XML (en fait, du XHTML5 + namespaces secondaires) qui est écrit à la main, formaté selon ma propre idée de comment le XML devrait être formaté, et cette idée n'est pas formalisable (selon mon humeur j'ai envie de mettre les attributs dans tel ou tel ordre). J'ai envie de faire des petits changements automatisés à ce XML (du genre « ajouter un attribut class="toto" à tous les éléments <blockquote> du namespace HTML qui sont inclus dans un élément de type <blog-entry> de mon namespace privé »), ces changements n'affecteront qu'un sous-ensemble très petit des balises. J'ai envie que le résultat soit exporté sous un format XML qui réalise le diff le plus petit possible par rapport à son entrée, et notamment, qui ne touche pas au formatage de toute balise qui n'a pas été modifiée par les changements. Il faut donc sauvegarder le formatage, faire les changements, et réappliquer le formatage.

@Damien: Normaliser du XML, je sais faire, ce n'est pas ça mon problème. Mon problème c'est que j'ai du XML non normalisé (tapé à la main), je veux le manipuler en préservant son formatage (non normalisé), cf. paragraphe précédent.

J'ai dû m'expliquer de façon obscure, parce qu'apparemment ce que je veux faire n'a pas été compris…

Fred le marin (2014-11-10T16:42:24Z)

Le Noeud Gordien (et en XML…)

<spoiler year="2014" visibility="all_people" secretlevel="polichinelle">
Cantor, il est comme Hugo (et même, peut-être, comme le Grand-Dieu-du-Ciel) : fort et fou.
</spoiler>
Il aurait fallu que XSLT respectasse déjà l'ordre lexicographique sur les noms d'attributs pour les ressortir toujours dans ce même ordre.
Ne pas perdre espoir, le temps des pionniers n'est sans doute pas terminé.
2014 n'est rien face à l'an 3001 !
Mais ce sera très (trop?) long, et une accélération de convergence serait la bienvenue.
A piece of advice anyone ?

Damien (2014-11-10T16:27:03Z)

Je connais 2 outils qui peuvent normaliser du XML, et pour ton besoin, il faudrait normaliser ton contenu une première fois pour servir de référence, puis normaliser après chaque modification ou groupe de modification.

Ces outils sont utilisés dans certains projets qui ont leur documentation en XML ou en Docbook, soit appelés dans la partie doc des outils de build (makefiles ou autre), soit dans des hooks de commit, afin que la doc de référence soit toujours normalisée. Et cela aide bien pour les diffs, comme tu le soulignais.

Les outils en question :

- xmllint (dans le paquet libxml2-utils)
Tu auras besoin des options de canonicalization, mais --c14n ne sera peut-être pas suffisante car les attributs ne sont pas triés. Tu peux essayer :

--c14n : save in W3C canonical format v1.0 (with comments)
--c14n11 : save in W3C canonical format v1.1 (with comments)
--exc-c14n : save in W3C exclusive canonical format (with comments)

(qui sont listées dans l'aide mais seule la première est dans le man)

- xmlformat (je ne le connais pas en détail, mais il est assez configurable)
http://www.kitebird.com/software/xmlformat/
c'est écrit en Perl ou en Ruby (il y a deux versions distinctes) et packagé dans Debian.

projetmbc (2014-11-10T15:18:48Z)

Bonjour.

Il serait bon d'avoir des exemples concrets de ce qui est cherché.

À première vue, si j'ai bien cerné le problème, j'opterais pour des outils du type "beautyfier" qui font l'analyse syntaxique d'un code pour un produire une version standardisée. En existe-t-il pour le XML ? Sûrement… Ici, je prendrais un outils extrayant les données du XML pour en produire une version standard, et une autre avec les attributs de mise en forme.