Journal Outils libre de manipulation XML

Posté par totof2000 le 10 février 2012 à 00:08.

Étiquettes :

fév.

2012

Bonjour.

je me permets d'écrire ici pour avoir votre avis sur les outils d'édition/manipulation de fichiers XML. Je suis à la recherche d'un tel outil. Pour les grincheux, je ne pose pas ma question dans le forum car je veux aller un peu plus loin qu'une simple réponse à une question. Je voudrais effectivement que vous répondiez à ma question si possible, mais surtout faire un petit état des lieux des éditeurs et outils de manipulation XML libres. Je souhaiterais

- connaitre les outils libres existant dans ce domaine
- que vous expliquiez ce que fait le ou les outils que vous utilisez
- ce qu'il ne fait pas
- dans quel contexte vous vous en servez, ou pourquoi vous ne vous en servez pas
- ce qui vous plait/déplait dans cet outil, et pourquoi cet outil par rapport à un autre.

Tant pis s'il ne répond pas à mon besoin, je ne pense pas qu'à (merci de l'indiquer quand même, ça m'aiderait).

S'il y a des outils pas libres que vous utilisez, je suis intéressé également. Vous pourriez indiquer quel(s) avantage(s) cet outil a par rapport aux outils libres, mais aussi les inconvénients, et manques.

Moi personnellement, j'ai besoin d'un outil libre qui me permette de visualiser/manipuler des fichiers XML. De préférence un outil qui permette de visualiser les fichiers sous forme d'arbre et éventuellement, si cet outil existe, qui puisse aider à générer des transformations xslt (un truc du genre tu ouvres un xml en entrée, un exemple de xml que tu veux obtenir en sortie et l'outil "prépare" le terrain aux transformations à appliquer pour obtenir ce que l'on veut). Pour moi le but principal est de faire des transformations de documents générés via Latex en un format intermédiaire (soit docbook par exemple, ou éventuellement odt), pour le transformer en ODT avec des styles prédéfinis.
Merci d'avance pour votre attention et vos commentaires.

# xml copy editor

Posté par rycks le 10 février 2012 à 00:26. Évalué à 3.

Tout est dans le sujet du commentaire, ça se passe ici:

http://xml-copy-editor.sourceforge.net/

C'est l'outil que j'ai cherché et qui est le plus "avancé" dans le domaine, mais je suis preneur de "mieux" ...

Je l'utilise pour vérifier que les fichiers XML que je produit:
a) sont valides d'un point de vue de la structure XML (tag ouvert fermé etc)
b) respectent le schéma RELAXNG que j'ai (j'ai les fichiers .xsd sur mon pc)

Mais je n'ai pas du tout cherché à faire ce que tu veux en faire ... ça m'intéresse d'avoir ton retour sur ce sujet !

a+
Éric

eric.linuxfr@sud-ouest.org
# Caisse à outil XML

Posté par Enzo Bricolo 🛠⚙🛠 le 10 février 2012 à 07:58. Évalué à 1.

Edition depuis le bureau (Win) : Xemacs (avec les bons modes), Xmlpad (léger) ou XMLspy (lourd et payant mais hyper complet)
Vérification de schema et manipulation/visualisation en ligne de commande : xmllint (libxml2)
Application de feuille de style : xsltproc (libxerces)
- [^] # Re: Caisse à outil XML
  
  Posté par Anthony Jaguenaud le 10 février 2012 à 08:55. Évalué à 1.
  
  Je m’étais laissé dire que emacs était mieux que Xemacs par un collègue… ce serait-il fourvoyer ?
  - [^] # Re: Caisse à outil XML
    
    Posté par Elfir3 le 10 février 2012 à 09:15. Évalué à 3.
    
    Perso, j'ai un 'alias emacs = "emacs -nw"' caché dans mon .bashrc ...
    Rien que l'utilisation de l'espace par l'interface gtk me dérange. Puis rien de plus beau que du texte dans un terminal <3
    - [^] # Re: Caisse à outil XML
      
      Posté par Julien Fontanet (site web personnel) le 10 février 2012 à 09:51. Évalué à 2.
      
      XEmacs != Emacs GTK (http://www.xemacs.org/)
      
      J'étais pareil avant, mais à force de galérer pour le rendu des couleurs et la gestion de la souris dans URxvt/Screen/Tmux, j'ai un peu abandonné le mode terminal.
      
      Je n'utilisais pas la version graphique parce que je la trouvais moche, mais une fois la menu-bar(-mode) et la tool-bar(-mode) virées, ça me convient très bien.
  - [^] # Re: Caisse à outil XML
    
    Posté par Enzo Bricolo 🛠⚙🛠 le 10 février 2012 à 20:32. Évalué à 2.
    
    Ca doit être le même collègue qui refuse d'installer "bash" parce que "le standard c'est ksh". Sinon Xemacs ou emacs ou vi ou notepad, le "mieux" c'est celui qui te convient.
    - [^] # Re: Caisse à outil XML
      
      Posté par Anthony Jaguenaud le 10 février 2012 à 21:03. Évalué à 1.
      
      Xemacs et un fork d’emacs pour utiliser X, car à une époque emacs ne fonctionnait pas en interface graphique (si j’ai bien compris). Mais aujourd’hui, emacs ayant le graphique et les deux ayant divirgé, j’espérer changer le troll du vendredi de vim/emacs en emacs/xemacs… J’ai raté mon coup.
- [^] # Re: Caisse à outil XML
  
  Posté par GeneralZod le 10 février 2012 à 14:20. Évalué à 3.
  
  Application de feuille de style : xsltproc (libxerces)
  
  xsltproc est fourni par libxslt développé par le projet libxml2
# xmlstartlet rend le XML moins pire :)

Posté par Bapt (site web personnel) le 10 février 2012 à 08:09. Évalué à 8.

xmlstartlet ça permet de maniper le XML presque comme un fichier texte normal que tu manipulerais simplement en cli :)
- [^] # Re: xmlstartlet rend le XML moins pire :)
  
  Posté par GeneralZod le 10 février 2012 à 14:17. Évalué à 2.
  
  Je ne peux qu'approuver, xmlstarlet permet de manipuler du XML en ligne de commande sans passer par un script en python ou quoique ce soit. Une petite astuce pour faire le diff de deux documents XML, j'ai dans mon zshrc (ça doit passer avec bash ou un shell un tant soit peu moderne).
  
  function diffxml() {
  if [[ $# != 2 ]]; then
  echo "FAIL: gimme two XML documents !"
  else
  diff -u <(xmlstarlet fo $1) <(xmlstarlet fo $2)
  fi
  }
  
  puis: diffxml A.xml B.xml
  - [^] # Re: xmlstartlet rend le XML moins pire :)
    
    Posté par Damien Thébault le 10 février 2012 à 16:27. Évalué à 1.
    
    Ça doit être possible avec "xmllint --format" également.
    
    Moi j'utilise xmlstarlet dans des scripts pour faire des requètes dans des XMLs et pour processer les résultats derrière avec d'autres outils en ligne de commande. C'est bien pratique ça évite de faire du python/perl/...
# Réponse universelle

Posté par zebra3 le 10 février 2012 à 09:34. Évalué à 1.

vim :-)

Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Réponse universelle
  
  Posté par barmic le 10 février 2012 à 10:07. Évalué à 2.
  Bien que j'apprécie beaucoup vim, il y a 2 points à noter :
  - peut être qu'avec un plugin ça va mieux mais de base il n'est pas très pratique pour l'édition XML
    - pas de complétion des balises ouvrantes par des balises fermantes
    - pas de surlignement rouge si une balise ouvrante n'est jamais fermée
    - il ne peut pas à partir d'un xsd, savoir quels balises tu peut ajouter à tel ou tel endroit
  - il ne fait pas de validation xsd, ni de requête xPath
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Réponse universelle
    
    Posté par zebra3 le 10 février 2012 à 10:47. Évalué à 1.
    
    Nan mais c'était ironique :o)
    
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Réponse universelle
      
      Posté par jyes le 10 février 2012 à 16:55. Évalué à 1.
      Il n’y a pas vraiment de raison d’être ironique sur ce point. Vim est loin d’être idéal pour traiter du XML car il n’a effectivement pas connaissance du schéma. Cela dit, même sans plugin particulier, le miens indique les balises qui ne sont pas refermées. De plus avec des trucs comme snipMate, il est assez simple de définir en même temps la partie ouvrante et la partie fermante de chaque balise.
      
      Bon, maintenant, j’admets que j’ai un usage assez limité d’XML dans Vim, mais j’écris quand même mes transformations XSLT avec et m’en sors finalement. Pour répondre à la question du journal, les outils que j’utilise pour traiter le XML ensuite sont:
      
      xmlstarlet pour la validation et des fois plus. Il est très bien mais au final je l’utilise peu car beaucoup de ses fonctions sont redondantes avec les autres outils;
      
      xsltproc pour appliquer les transformations XSLT très rapidement et simplement;
      
      saxonb pour les transformations XSLT 2.0. Saxon B est libre mais relativement limité comparé à la version non-libre de Saxon. En pratique, Saxon B a toujours répondu à mon besoin quand xsltproc devenait insuffisant. Je n’ai jamais utilisé d’outils propriétaire car c’est mal et les outils libres sont de très bonne facture. Quand on l’utilise par un simple appel en ligne de commande, Saxon B présente néanmoins le défaut d’être en Java et de nécessiter un temps de chargement assez long relativement au temps de traitement des règles XSLT. En règle générale, je préfère donc xsltproc (ou pour un binaire, les libs qu’il utilise, soit libxml2 et libxslt1).
      
      #!/bin/sh # Utilisation du processeur XSLT Saxon B depuis la ligne de commande CLASSPATH=/usr/share/java/saxonb.jar \ java net.sf.saxon.Transform -ext:off -s:$2 -xsl:$1 -o:$3
      
      Note que par rapport au but de l’auteur, le miens va en sens inverse, j’utilise essentiellement les feuilles de style XSLT pour transformer du XML en LaTeX qui reste l’outil idéal pour produire de « beaux » documents finaux.
      - [^] # Re: Réponse universelle
        
        Posté par totof2000 le 10 février 2012 à 18:06. Évalué à 2.
        
        Note que par rapport au but de l’auteur, le miens va en sens inverse, j’utilise essentiellement les feuilles de style XSLT pour transformer du XML en LaTeX qui reste l’outil idéal pour produire de « beaux » documents finaux.
        
        bah, pour moi Latex reste quand même un outil bien plus efficace pour écrire de la doc qu'OpenPffice.
# jedit + plugin xml + plugin sidekick

Posté par steph1978 le 10 février 2012 à 10:33. Évalué à 3.

il fait:
- coloration syntaxique
- navigation dans l'arborescence du fichier
- repliage visuel des balises
- indentation
- validation
- conformité dtd ou schema
- téléchargement dtd ou schema déclaré
- navigation dans l'arborescence du fichier avec le plugin sidekick
- auto complétion des balises, en utilisant le schema si déclaré
- recréation de dtd à partir du fichier xml d'exemple

il ne fait pas:
- rien qui me manquerait, sauf peut être la manipulation de très gros fichier, mais il y d'autres outils qu'un éditeur de texte pour ça.
- recherche/filtre xpath
- consommer peu de mémoire (c'est du java quand même).
# xmlgrep

Posté par coïn le 10 février 2012 à 10:57. Évalué à 1.

il existe XMLGREP http://xmltwig.org/xmltwig/tools/xml_grep/xml_grep.html qui est pas mal je trouves.

A compléter avec d'autres outils bien sur
# les poids lourds

Posté par florent le 10 février 2012 à 11:20. Évalué à 2. Dernière modification le 10 février 2012 à 11:23.

En complément des réponses précédentes, si tu as quelques centaines de MegaBit de RAM dispo, tu peux essayer les IDE poids lourds : eclipse ou netbeans par exemple.

On peut les trouver lourds, lents, démesurés ... mais si le PC le permet, ils font vraiment beaucoup de chose (cf http://xml.netbeans.org/) qui simplifient la vie.
Personnellement, j'utilise netbeans (eclipse est sûrement tout aussi bien) régulièrement. Il a l'avantage de proposer, en un seul outil et avec une installation de base, beaucoup de fonctionnalité que j'avais au part avant, mais dans plusieurs outils. Donc ça me fait gagner de temps. tant pis pour la RAM qui de toute façon ne servait pas.

Pour ouvrir rapidement un xml, geany est pas mal (beaucoup mieux que gedit). Sinon oui vim c'est super. Surtout en ssh ... Là netbeans c'est pas top.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.