Discussion :

[alain.couthures]

Je suis ce qu'on appelle un XML Geek!

Je travaille à l'international avec des personnes impliquées dans les travaux du W3C et je n'ai pas du tout le sentiment que le XML va s'arrêter.

On constate plutôt un emballement où il apparait que plus tout est fait en XML plus on a de valeur ajoutée.

OK ce n'est pas pour demain mais pour après-demain.

C'est une vraie remise en cause des valeurs des langages de 3ème génération et cela va demander d'arrêter de "pisser du code" et de réfléchir à la place !!

XML n'est qu'une notation, la programmation déclarative est derrière tout ça.

[dtrosset]

Si par programmation déclarative il faut comprendre quelque chose du genre de XSLT, alors il faudra trouver autre chose pour transformer du XML. Ce XSLT est véritablement imbuvable. C'est ce qui m'a fait changer ma chaîne d'outils de documentation. J'utilisais DocBook, du XML, XSLT, de XML, et puis FOP, encore du XML.

Code :

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

DocBook --[XSLT]--> HTML + FOP --> PDF

J'ai changé pour des outil plus simples à apréhender, plus simples à configurer et à personnaliser, avec lesquels j'écris simplement du text, et qui sont pour finir encore plus puissants, sans XML.

Code :

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

reStructuredText --> HTML + Latex --> PDF

Didier

[ezmac]

en theorie XML est un bon moyen pour échanger des données, mais il es trop lourd (les balises pèsent presque plus que les données).

il n'y a aucun bénéfice a que ça soi lisible par un humain (c'est impossible sauf parser).

structure trop compliquée, comme l'on l'a dit içi, c'est presque un nouveau job à part entière.

et ce qui est fou est que les balises ne sont pas standardisées à niveau mondial (rajoutez un dictionnaire).

+ 1 pour JSON.... je l'utilise internement, mais je me suis fai taper sur les doits car il fallait que ce-là soit tout du xml.

[Morbo]

Pour nuancer cette expérience, je suis au contraire très satisfait de XSL-T! Même si j'ai pris un peu de temps à comprendre cette approche déclarative, je l'utilise maintenant facilement.

Pour ma chaine documentaire, j'utilise XML de bout en bout.
C'est du WorldML à la base avec des références aux données possibles graphiquement via un XSD générique.
La rédaction peut donc être faites par des acteurs non technique.
Des formulaires web générés dynamiquement et pour finir du PDF via FOP.
L'intérêt étant l'évolutivité, une source xml initialement statique, peut plus tard être générée dynamiquement via nouveau un XSL-T, qui lui même peu être généré, ....

Néanmoins, dtrosset je serais très intéressé d'étudier une autre approche. Si tu as des liens, je prend!

[briegel]

Un format super, dans certaines circonstances : dans une application web, qui doit générer du contenu et le stocker, le XHTML est stocké dans un doc XML, le nombre de balises est très réduit par rapport au contenu, on évite le XSS sans efforts, je ne parle même pas des injections (SQL), et quand on veut récupérer le contenu, il suffit de copier bêtement le bon noeud et tout son contenu.

Alors personnellement, j'ai pas trouvé plus efficace que le XML pour cette utilisation.

Si je devais avoir un grand nombre de variables courtes à stocker, je ne penserais même pas à XML...

[Erwy]

Si par programmation déclarative il faut comprendre quelque chose du genre de XSLT, alors il faudra trouver autre chose pour transformer du XML. Ce XSLT est véritablement imbuvable.

Pas l'avis d'Ooo.
Ooo, pour tout ce qui est changement de format, n'est qu'une grosse librairie de feuille XSLT, que vous enregistrier en .DOC, .TXT ,PDF ou autre, vous transformez le fomat D'Ooo (qui est du xml) en votre cible via une feuille XSLT (qui transforme du XML en n'importe quel format texte).
Ooo vous permet aussi d'ajouter vos propres filtres XSLT.
Cela vous permet donc de lire/écrire/modifier vos fichier XML sous Ooo si vous maitrisez ce langage.

[thelvin]

Moi aussi je trouve que XML est utilisé à torts et à travers, et comme j'en fais les frais comme tout le monde, je comprends ce ras-le-bol général. Oui, XML, il faudrait passer à autre chose, ne pas rester dans le statu quo.

Mais XML est un bon outil, juste très mal utilisé.

Je vois de nombreuses objections :

- XML est trop compliqué !

Balivernes. Utilisez ce dont vous avez besoin, ignorez le reste. On apprend à le faire une fois, c'est vite fait, et ça marche pour la vie.
Le jour où vous en aurez besoin, du reste, vous serez contents que ça soit au moins possible en XML.

- JSON c'est plus lisible !

Balivernes. JSON n'est plus lisible que XML que là où un properties ou équivalent, ou un CSV, serait encore plus lisible.

- JSON c'est mieux !

J'aime beaucoup JSON, mais il ne gère pas les flux (ouais, ouais, ok, il les gère mal, pas pas.) Il est beaucoup plus limité. Son intérêt, c'est qu'il s'intègre encore mieux que XML, qu'il gère les données hiérarchiques et séquentielles, qu'il est très léger, et assez lisible. Splendide format de communication.

- YAML c'est mieux !

YAML est mon petit chéri, mais il ne gère pas les flux (cherchez pas d'excuse, il les gère pas.) Par rapport à XML, il s'intègre moins bien, et il est plus limité. Parfait là où il suffit et si on sait bien l'intégrer.

- XML est étudié pour être lisible par un humain mais ça sert à rien !

Foutaises. Pour un programmeur, cela permet de résoudre de nombreuses problématiques de gestion de données, à partir de rien, en quelques heures, rien qu'en se reposant sur les APIs XML.
Quand on ne sait pas se servir d'un bon outil, on ne dit pas qu'il ne sert à rien.

- XML est trop lourd !

XML est lourd, c'est sûr. Mais ce n'est pas si souvent qu'on en a quelque chose à f***e.
Utiliser php ou Java ou C# ou je sais pas quoi, c'est plus lourd que du C bas niveau. Mais pas inutile.

- XML comme configuration c'est trop compliqué !

On est d'accords. Ne le faites pas, à moins d'avoir une bonne raison.

(Je crois que j'ai fait le tour de mes objections.)

[_skip]

Mon avis est qu'il faut separer logique (le code) et données (la config). La la config doit rester dans un fichier externe (xml, fichier plat, json etc).

Pour la citation, il faut voir ce qu'on appelle de la configuration, pour moi, c'est quelque chose de souple par définition qu'on peut être amené à modifier en tout temps, spécialement lors du déploiement sur la machine final.

Or dans le cas de JSF, tu définis quelle action sur un formulaire amène quelle face (une vue au sens JSF), et quelle face construit quel bean. En fait c'est même pas souple, c'est de la configuration figée qui n'apporte rien sauf un code moins homogène, moins typé et qui explose en exécution alors que ça pourrait être géré à la compilation.

Ce n'est pas raisonnablement des choses que tu vas modifier, ce que tu modifies ce sera plutôt les connexions à la base de données, éventuellement la gestion des logs, bref des propriétés pour lequel cela fait du sens de laisser externe à l'application.

Ce n'est pas l'usage de XML qui est abusif. Si on utilisait JSON à sa place pour le web.xml, dans struts et pour maven, on aurait les meme critiques contre ces format.

100% d'accord

Le vrai probleme ets plus philosophique. C'est le choix fait dans la plupart des frameworks jee d'etre modulables au maximum. Ce qui engendre necessairement un max de config donc un max de XML.

Sauf qu'au bout d'un moment ça devient irréaliste de taper plus de XML que de code java surtout lorsque les schémas commencent à partir dans tous les sens avec des références partout. Et tout ceci pour des choses figées qui gagneraient à être écrite en code, profitant ainsi du typage et de la vérification à la compilation.

[cs_ntd]

Bonsoir à tous

Personellement, je ne connais pas/je n'ai pas encore trop eu à souffrir du XML, que je n'ai que rellement utilisé (càd avec API & cie) que depuis peu.

En fait je suis là juste pour vous dire que (d'après ce que j'ai lu), vous êtes pas sortis des problèmes d'utilisation abusive !

Pourquoi je dis ça ?
Parceque dans mon école (et pas que dans la mienne), on est entrain de nous inqulquer le culte du XML , c'est fou !

On nous explique en effet que XML est désormais à la base de tout, que c'est LA solution en matière de configuration diverses, LE moyen de paramétrage absolu, ZE chose pour les BDD, que c'est utilisé partout, dans tous les domaines, enfin que XML c'est vraiment l'avenir.



Donc on nous apprends à bien configurer les applications avec du XML, bien stocker les paramètres en XML, bien utiliser le XML partout.

Ceci étant dit, il me semble à moi aussi qu'un fichier .ini est relativement moins lourd et plus simple à mettre en place que bourriner du XML de tous les côtés
Mais je crois surtout que chez les professeurs, le XML ça a vraiment la côte et qu'une génération de developpeurs formatés au XML va avoir du mal a empecher une utilisation abusive...

[tpruvot]

Pour avoir fait récemment un générateur JSON (serialiation de classes complexes) je trouve que ce format JSON est tres lisible pour les classes justement, car les membres sont nommés facon tableau associatif php
ex :

en JSON

Code :

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

1
2
3
4
MonTrait: {
  Point1: {x: 5, y: 5}
  Point2: {x: 8, y: 10}
}

en YaML

Code :

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

1
2
3
4
5
6
7
MonTrait:
  Point1:
    x:5
    y:5
  Point2:
    x:8
    y:10

Il a l'avantage sur le YAML ne pouvoir etre compacté (espaces tabulations, retour chariots ignorés) en YAML une tabulation rend le fichier invalide... ce qui oblige à avoir un éditeur de texte qui gére l'ajout suppression d'espaces sur des paragraphes... testé en force dans Symfony... une vraie machine a gaz en ce moment... doc et version en cours déphasée etc..

Mais il est aussi moins sécurisé que le XML... exemple simple, on envoie une requete à un serveur imaginons caractère par caractère via un terminal,...
le XML possède un tag de debut et de fin en général identique... on sait donc exactement quand le fichier ou le bloc se termine...

Ce cas de figure est en fait transposable à n'importe quel fichier (erreur de lecture, transfert interrompu, fichier mal enregistré ou abimé etc...)


En JSON... ces caractères } et ] peuvent etre inclus dans une chaine et mal interprétés... Il faut constamment comptabiliser les ouvertures fermetures de bloc et surtout, il n'y a pas forcément de {} en début et fin...


En tout cas le XML pourquoi pas mais ca devrait etre interdit sur des fichiers de plus de 100ko !

[powel]

Bonsoir à tous,

quelqu'un qui sait développer est largement capable d'ouvrir un éditeur hexadécimal pour modifier un fichier binaire contenant une configuration.

Beaucoup de configs. ne demandent pas une structure complexe nécessitant du XML ou même .INI mais on a tous le fantasme d'essayer de rendre l'informatique "humaine" et "intelligente" en essayant à tout prix de rendre tout lisible par n'importe quel humain même celui qui n'est pas concerné !

Ainsi sont nés fichiers de configs. textuels et par exemple XML, tout comme les langages de programmation bienvenus dans certains cas mais extrêment lourds de mots dans d'autres.

Enfin marrant de penser que le premier noyau UNIX occupait 16 Ko (pas 16 Mo) ... aujourd'hui 16 Ko c'est tout juste suffisant pour stocker un fichier de config.

[Bruno PICART]

Je ne pense pas que l'on soit rentré dans le dogme, j'aimerai bien savoir ce qui t'as amene a cette conclusion. STP.

Plusieurs choses : j'avais demandé à quelqu'un il y a quelques temps à quoi pouvaient bien servir les fichiers XML. Il m'a répondu : "à programmer", rien d'autre.
Je lui ai alors demandé de m'expliquer comment utiliser XML dans une mini-appli résolvant les équations du second degré : pas de réponse.

Même s'il m'avait répondu : utile pour stocker les coefficients a,b et c de l'équation, il aurait au moins compris la finalité des fichiers XML, même avec un tel cas de figure où une telle implémentation ne servirait strictement à rien.

Autre chose : on utilise souvent la technologie XML pour implémenter des fonctionnalités plus faciles à développer autrement. Par exemple, pour exporter une base de données de taille moyenne, la méthode une table = un fichier CSV est suffisante.

Encore autre chose : pourquoi Microsoft a-t-elle souhaité faire normaliser son implémentation-maison de XML, tout en la laissant libre ? J'y vois une redondance, comme si posséder sa propre norme était un argumentaire en sa faveur. D'autres sociétés sont-elles intéressées pour obtenir la normalisation de leur propre système de balises ? Je n'en doute pas

Ce qui est nécessaire, c'est de mettre en oeuvre une bonne pratique au bon moment. XML est devenu quasiment un standard pour le portage de données d'une appli vers une autre. Mais s'il existe d'autres alternatives moins lourdes, à performances équivalentes, utilisons-les.

[CesarR]

Bien sûr : JSON Schema est fait pour ça.

C'est un standard?

[berceker united]

Je rejoints la plupart des observations, XML utilisé à tord et à travers. Mais même quand il est utilisé pour ce qu'il est prévus de faire je vois des trucs hallucinant. Je vais prendre le simple exemple d'Apple avec Itune. Ce dernier utilise un fichier XML pour stocker toute les informations musique. En soit pourquoi pas, le XML peut être utilisé pour ça mais quand je vois comment ils ont structuré leur XML fait que c'est illogique et difficilement exploitable.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[...]
<dict>
			<key>Track ID</key><integer>49</integer>
			<key>Name</key><string>The Edge Of The Blade</string>
			<key>Artist</key><string>Various Artists</string>
			<key>Album</key><string>BLADE</string>
			<key>Genre</key><string>Autre</string>
			<key>Kind</key><string>Fichier audio MPEG</string>
			<key>Size</key><integer>4037944</integer>
			<key>Total Time</key><integer>252107</integer>
			<key>Date Modified</key><date>1999-10-23T10:00:00Z</date>
			<key>Date Added</key><date>2010-01-27T14:25:15Z</date>
			<key>Bit Rate</key><integer>128</integer>
			<key>Sample Rate</key><integer>44100</integer>
			<key>Persistent ID</key><string>ECFCC65F0302CBFE</string>
			<key>Track Type</key><string>File</string>
			<key>Location</key><string>file://localhost/F:/CDs/Mp3%20Tech%2006/BLADE/01_Mystikal%20-%20The%20Edge%20Of%20The%20Blade.mp3</string>
			<key>File Folder Count</key><integer>-1</integer>
			<key>Library Folder Count</key><integer>-1</integer>
		</dict>
[...]

ça c'est un des problèmes qui est récurant lorsqu'on vous donne un XML mal structuré vous êtes obligé de faire des noeuds dans votre code pour gérer cela.

[bretus]

Après, sur de gros volumes de données, l'usage du XML peut être justifié

Justement pas tant que ça... Le lisibilité n'est pas là pour la pauvre machine qui se fade les lectures. Un XML de 400Mo fait voler un éclat bien des parseurs sur des machines moyennes.

Quand aux écritures, c'est une vrai catastrophe. Modifier une balise, et c'est parti pour le grand balais d'écriture.

Ce format n'a rien de structuré du point de vue de la machine. Il n'est lisible qu'en séquentiel, l'accès à un élément impose la lecture de l'intégralité du fichier...

Du point de vue "métaphysique", on peut se demander l'intérêt de la répétition pour chaque entrée, en double, des métadonnées :

<mon-nom-de-variable>...</mon-nom-de-variable>

JSON est plus pragmatique à ce niveau là (et distingue les tableaux des objets au passage).

<parenthese>

En JSON... ces caractères } et ] peuvent etre inclus dans une chaine et mal interprétés... Il faut constamment comptabiliser les ouvertures fermetures de bloc et surtout, il n'y a pas forcément de {} en début et fin...

Vu que l'on écrit pas un parseur tous les jours, ce n'est quand même pas catastrophique. Une technique simple de compilation permet de lever tous ces problèmes de contrôles d'ouvrants/fermants imbriqués : la bonne vieille pile (empilage sur [ et { dépilage et vérification sur } et ]...)

</parenthese>


Je trouve amusant de voir qu'XML se généralise plus en raison des outils qui l'accompagnent, qu'en raison du format lui même.

Alors, XML pourquoi pas, mais sous contraintes :
- données statiques ou presque et légères
- échange de données ("ponctuel", avec conversion dans un format de travail à la première lecture/validation)
- données majoritairement textuelles
- données à architecture simple (hiérarchique) Ca n'est qu'un arbre...
Et non :
- stockage et manipulation de données dynamiques (format non adapté aux créations/modifications/suppressions sur un disque dur)
- données non hiérarchiques, relationnelles (où il y a non pas un simple arbre sous-jasent, mais à minima son papa mathématique : le graphe)

[dtrosset]

Et comme je l'ai déjà lu je ne sais plus où :

Je bénis le fait qu'XML n'existait pas quand la structure du fichier /etc/passwd a été créée.

Didier

[dtrosset]

Un XML de 400Mo fait voler un éclat bien des parseurs sur des machines moyennes.

Oui, mais ça ,c'est parce que tout le monde veut faire du DOM. C'est complètement inadapté pour de gros volumes de données. Parce qu'en plus d'utiliser des quantités de mémoire astronomiques, DOM rajoute de la latence. Et là c'est un problème insoluble, avec DOM, il faut parser l'intégralité d'un fichier XML avant de pouvoir commencer à traiter les données. Ce n'est pas possible de traiter les données au fur et à mesure avec DOM.

Didier

[Erwy]

ça c'est un des problèmes qui est récurant lorsqu'on vous donne un XML mal structuré vous êtes obligé de faire des noeuds dans votre code pour gérer cela.

C'est ce que je disais plus haut, tout le monde l'utilise mais une bonne partie n'importe comment
D'ailleurs , même des formats comme ceux de Ooo ou office sont à moitié aberrants.
XML a été développé pour séparer les données du traitement, comme pour une base de donnée relationnelle, on doit normalement structuré les données selon leur nature et non selon leur utilisation (même si on optimise parofis on évite le 1 requête=1table), mais c'est quelque chose qui est rarementr fait et qui donne de réelle abheration , malheureusement je vois ça aussi sur des bases de données

En réalité , comme pour une base de donnée, le point fort de XML n'est pas le inter-applicatif, mais le multi-utilisation quand il est bien formé.
Un exemple, sur une application sur laquelle j'ai travaillé on m'a demandé de réalisé un mécanisme de requêtage complexe pour l'uilisateur (en gros possibilité d'imbriquer des ou et des et dans une clause where, mais le resultat final décide aussi de quel table sont appelé, quel donnée etc....)
Pour ceci je génére un ficher xml assez simple (arbre de bloc et/ou) qui sont utilisé de différente façon
1) Transformation immédiate en requête(s) sql via XSLT avec d'autres fichiers xml contenant les "variables"

2)Stockage en base en vue d'une réutilisation : 2 points fort
- si la base change on ne modifie generalement que les fichiers xml de variable, la "requête" stocké reste juste
- Si on est obligé de modifié la structure du XML de requête (à l'origine on utilisait deux formats 1 pour des requêtes plus simples l'autre pour des complexes) il suffit de faire passer un script sur la base qui transforme tous les fichiers XML concernés (toujours très simples quand on maitrise XSLT)

3) Production de stat : pas seulement quand on envoie des requêtes mais aussi
- quels critreres de recherche ?
- complexité moyenne des requetes (profondeur des abres par exemples)?
- quels résultats demandés ?
- sous quels formes ?
etc.....

Ce qui permet d'optimiser la base en fonction de son utilisation réelle

Tout ceci est non seulement bien plus simple qu'avec des chaines de caractères mais aussi plus sécurisé car les champs sont bien typé et structuré suivant leur sens.
Un exemple d'abberation dans cette discussion

Et, c'est vrai, il est terriblement simple de faire une erreur dans un fichier XML. Je me rappellerai toujours de cette virgule manquante dans un fichier de conf struts qui me donnait une jolie page blanche (plus qu'à modifier le fichier et relancer le serveur).

La virgule ne fait pas partie de la structure d'un XML, donc pour je ne sais quel raison tordue, on a inclu du traitement de chaine en plus du traitement XML et quand il y a un problème on accuse le XML
Si il y a une sépration sémantique des données, alors celle-ci doit être manifeste dans la structure même du XML,comme on le ferait dans une BDD et non pas dans de l'analyse de chaine à posteriori

[alain.couthures]

Les bases de données XML émergent, fini les gros fichiers.

Le streaming va sortir dans la prochaine version de XSLT (je le sais, j'étais invité à XML Prague 2010 )

En fait, la vraie révolution, c'est bien la génération de XML. En XML, il n'y a aucune distinction entre programme et donnée (je sais, ça fait hurler les papis de la 3ème génération car ils se sont battus pour cette séparation!). C'est en cela que c'est super productif de bout en bout.

Ce n'est pas très important que le XML soit lisible humainement. Il suffirait d'avoir enfin un éditeur XML intelligent pour s'en passer. Disons que la lisibilité facilite l'interopérabilité.

Alors je félicite les profs d'info qui ont compris cela. La formation n'est-elle pas là pour ouvrir les yeux vers les futurs horizons ?

Oui, le tout XML est meilleur. Je comprends que s'entendre dire, quand on est un jeune programmeur Java, que Java n'est qu'une sorte de langage assembleur par rapport à la programmation XML, ça fout les boules mais c'est ça l'informatique, on conceptualise de plus en plus.

[Erwy]

Ce n'est pas très important que le XML soit lisible humainement. Il suffirait d'avoir enfin un éditeur XML intelligent pour s'en passer. Disons que la lisibilité facilite l'interopérabilité.

Moyennement d'accord
Quand j'interroge ma base , je suis bien content quand j'ai un programme qui plante à cause des données de pouvoir simplement lire/afficher mon fichier xml pour trouver les données problématiques plutot que devoir me farcir un objet ou un fichier csv...
Pareil quand j'envoie des données sur mon serveur, ça me facilite la vie.