Que pensez-vous du XML
Faut-il passer à autre chose ?

Le , par grunt2000, Membre confirmé
Bonjour,

Ca y est. Au plaisir d'ouvrir un livre Java récent et de découvrir qu'un mot-clé supplémentaire (pour les pratiquants, une annotation) dans mon code source saura remplacer un fichier XML dont la présence était auparavant obligatoire, je me dis que nous sortons peut être d'une période où tout n'était qu'XML. Jusqu'à l'indigestion.

Il y en eu partout et pour tout. Si pour l'échange de données entre systèmes il avait des atouts certains, je défends la thèse qu'il a été utilisé abusivement. Le paramétrage des composants, par exemple, est trop souvent passé par lui.

Et cela a mené à des situations extrêmes. Il devenait parfois plus délicat de réussir son XML de paramétrage ou de compilation que le propre code source que l'on voulait faire fonctionner. Java J2EE - mais est-il le seul? - nous a pendant des lustres gratifiés de mille fichiers XML à produire pour tout et n'importe quoi. Une source de gêne certaine.

Maven 2, qui sert à la construction de projets et qu'il est de bon ton de trouver merveilleux (alors je vais essayer de l'écrire aussi: "C'est bien ma veine!"), a atteint à mes yeux des sommets de farfeluterie et d'obscurité dans ses fichiers pom.xml, décrivant les travaux qu'il avait à mener.

Et aujourd'hui vient (ou revient) le paramétrage par script, fondé sur un langage dédié à l'application que l'on veut paramétrer. Je pense que c'est la bonne solution.
Il assurera une meilleure clarté et une évolution plus facile si ces langages se fondent sur des grammaires claires.

Mais il est tard. Je pense que bien qu'XML ait eu beaucoup d'atouts, il a été utilisé souvent d'une manière qui a généré de la complexité. Qu'il est un révolutionaire des années 2000 dont on a le droit de tirer un bilan, d'utiliser "notre droit d'inventaire", comme on dit.

Qu'en pensez-vous?

Grunt.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de thelvin thelvin - Modérateur http://www.developpez.com
le 12/04/2010 à 10:39
Citation Envoyé par powel  Voir le message
C'est pas vraiment normal d'avoir un nom de balise fermante pouvant être ignoré par le parser alors que son absence rend invalide le code XML. Résultat d'avoir voulu faire un compromis.

Je veux bien que ça soit suboptimal au niveau de la rigueur explicitement exigée des parseurs. Toutefois, cette redondance a ses avantages au niveau lisibilité, bien que ça ne soit pas systématique. Cette considération est plus importante.

Par ailleurs, même en admettant qu'il s'agisse d'un défaut de XML, ce seul argument n'invalide pas l'intérêt de XML. Il dirait juste que "XML peut être mieux" et si on veut mon avis, oui, XML pourrait être amélioré, et surtout pourrait avoir été mieux fait au départ. Comme tout, quoi.
Par contre, en conclure que XML ne devrait pas exister, ou pas être utilisé ce qui est la même chose, c'est débile.

Citation Envoyé par powel  Voir le message
Un autre aspect est tout simplement le gaspillage de place, de temps et de complexité en code. Même si nos machines sont de plus en plus puissantes, beaucoup de gens ont (heureusement) encore le goût de l'efficacité.

Dans le cas général le goût de l'efficacité est non seulement inutile, mais contre-productif. La machine devrait travailler, pas nous.

Citation Envoyé par powel  Voir le message
Tant que nos machines ne prendront pas d'initiatives, il vaut mieux utiliser des formats rigoureux et ciblés et non des formats suggérant une cohabitation "forcée" homme-machine comme si cette dernière allait se mettre à penser.

Non. Personne n'a jamais dit que la machine devait essayer de penser pour lire du XML.
Avatar de Erwy Erwy - Rédacteur http://www.developpez.com
le 12/04/2010 à 10:58
Citation Envoyé par powel  Voir le message
[..]
En fait tout est dit dans ma réponse à Sevyc64, "sens pratique" ou "bon sens" : au nom d'un idéal ou d'une utopie, il ne faut pas systématiquement vouloir rendre lisible une structure de données inter-machines par un humain. Ou par exemple rendre compréhensible un fichier de configuration par un non-informaticien et complexifier par un parser la lecture de celui-ci.
[..]
Lorsqu'un programmeur doit contrôler un circuit intégré, il manipule des bits et il est parfaitement dans son élément. Un fichier de config. c'est souvent beaucoup de booléens mais par une inconsciente envie de lisiblité par "n'importe qui", on écrit des dizaines d'octets juste pour activer ou désactiver un bit ce qui bien sûr devra en plus être parsé. Je trouve que la soif de rendre l'informatique humaine nous conduit à des excès.
[..]

Tout est dit là.
Une logique strictement axé applicative, genre robotique ou autre...

Désolé mais quand on travaille essentiellement sur de la donnée que l'on étudie, manipule,transforme... On n'a besoin d'avoir quelque chose de comprehensible pour l'humain et si c'est en plus lisible c'est un plus énorme.
Je ne compte plus les galère sur des bases de données ou à cause d'un caractères particulier ou d'un nouveau format de donnée on n'était obligé de changer de version de l'editeur SQL, voir d'éditeur pour pouvoir travailler.

Comme déjà dit, va peut être falloir que certains se sortent de leur logique strictement applicative, il y a autre chose que cela en informatique et pour ne pas comprendre pourquoi un format de donnée/document doit être comprehensible pour un être humain via un éditeur de texte, c'est qu'on n'a jamais bossé dans des domaines les utilisant...
Avatar de sekaijin sekaijin - Expert éminent http://www.developpez.com
le 12/04/2010 à 11:43
sans être aussi catégorique. je pense que forma lisible par l'homme et la machine est souvent un plus

il n'y a pas très longtemps je consultais un mail via un webmail loin de chez moi loin de mon boulot avec une machine sur laquelle je n'avais pas mes outils.

un collègue m'alertait sur un problème d'échange entre deux applications d'un SI qui en compte des milliers

était joint le fichier contenant le message fautif. le format du document est un format d'échange mis au point à la grande époque de l'OSI et ces nombreuse couche. format de niveau 7 soit donc la couche applicative. (et non présentation) donc dédié à la lecture par une machine.

j'ai ouvert le truc est j'ai commencé à scruter le message qui heureusement pour moi était court.
bref lire dans notepad un truc destiné à une machine n'est pas simple.

à côté de moi une personne travaillant elle aussi dans le même genre de SI me demanda si je lisais le format en question dans le texte et ma réponse fut que j'essayais. elle me proposa son aide et me lu la chose comme vous ou moi un roman. et en rein de temps je trouvais et résolvait le pb.

après une petite discussion elle m'avoua être souvent confrontée à ce genre de pb et qu'elle avait fini par lire ce format directement dans les flux. l'utilisation d'outils étant couteuse en temps (extraction du doc de son domaine, I.e. transfert depuis un domaine sécurisé qui normalement l'interdit du fichier chargement d'un outil lourd pas toujours dispos)

pour ma part je n'y arrive pas aussi facilement et j'ai au magique un tout petit outil qui transforme se format en xml et là les bloc apparaissent et tout s'éclaire.

lorsqu'on travaille ainsi sur des échanges les exploitants finissent par lire des format qui ne sont pas du tout adapté à l'homme simplement parce qu'il ont étés pensé pour la machine en imaginant que jamais on aurait besoin d'aller y voir.

j'ai vu à l'époque un exploitant prendre un rack de cartes perforé les passer en vitesses ralentir au milieu du tas (gros le tas) et en regarder quelques unes. puis il a sortit un poinçon et a fait un trou. à l'étonnement de tous il a répondu "c'est toujours la même erreur!"

tout ça pour dire que oui c'est bien d'optimiser pour la machine mais qu'il faut aussi penser que souvent le format en question va se retrouver devant des yeux humain même si ce n'est pas sa vocation.

A+JYT
Avatar de yann2 yann2 - Membre expérimenté http://www.developpez.com
le 12/04/2010 à 15:26
Bonjour

En réalité, il est bien dommage qu'on s'éloigne du post initial (je pense que le changement de titre du post par la modération n'y est pas pour rien).

La motivation de ce thread part à la base d'un constat de la prolifération des fichiers de configuration au format XML dans une application J2EE.

D'ailleurs les premières réponses du thread vont dans ce sens. Et, c'est aussi pour ça que j'ai ironisé sur le fait que je n'ouvre pas mes fichiers odt à coup de winzip + notepad

La configuration d'une application doit être comprise par l'homme, doit être facile à compléter ET ne doit pas demander plus de réflexion, de temps ou d'argent que le développement de l'application elle même.

Bref, ça a dévié sur l'utilité du format XML alors qu'au départ, j'ai le pressentiment que personne ne le mettait en doute.

Voici les propres mots de l'auteur du thread :

Il y en eu partout et pour tout. Si pour l'échange de données entre systèmes il avait des atouts certains, je défends la thèse qu'il a été utilisé abusivement. Le paramétrage des composants, par exemple, est trop souvent passé par lui.

Est à ce sujet, on veut quelque chose de plus simple que le XML, pas du binaire

Yann
Avatar de thelvin thelvin - Modérateur http://www.developpez.com
le 12/04/2010 à 16:33
Citation Envoyé par yann2  Voir le message
Bref, ça a dévié sur l'utilité du format XML alors qu'au départ, j'ai le pressentiment que personne ne le mettait en doute.

Au départ peut-être pas, mais à la longue...

De toute façon, je ne pense pas qu'il reste grand-chose à débattre sur la question de départ, si ?
Avatar de yann2 yann2 - Membre expérimenté http://www.developpez.com
le 12/04/2010 à 16:40
Salut

Citation Envoyé par thelvin  Voir le message
Au départ peut-être pas, mais à la longue...

De toute façon, je ne pense pas qu'il reste grand-chose à débattre sur la question de départ, si ?

Et bien, je pense que ça aurait été intéressant de débattre sur le sujet initial.

Nous pouvons bien entendu débattre de l'utilité du format XML mais, pour ma part, à moins de voir des arguments de fou, je pense que dire que le langage XML est une ineptie est une ineptie

Donc je vais me retirer.

Yann
Avatar de bretus bretus - Membre éprouvé http://www.developpez.com
le 22/04/2010 à 9:01
Citation Envoyé par Oscar Hiboux  Voir le message
Ah, et par quelle magie tu n'aurais pas besoin de lire un fichier séquentiellement pour y chercher qqchose ?

C'est allucinant de voir que bien des informaticiens considèrent l'accès direct comme de la magie. Tu penses que quand tu ouvres "C:/toto/monfichier.xml", windows se farci la lecture de l'intégralité de ton disque dur?
Tu as une idée de ce qui se passe dans un Oracle, Postgres, SQLite etc... quand tu recherches "valeur"=12 dans une table où "valeur" est indexée?
De là à savoir écrire ces moteurs de stockage, il y a des limites.

Parce que quand tu modifies un fichier YaML (par exemple) tu n'as pas besoin d'un balai pour le réécrire ?

Quand tu modifies tout fichier à lecture séquentielle, tu dois le ré-écrire dans son intégralité. Quand tu modifies un fichier où les enregistrements on une taille définie, tu peux rentabiliser "seek".

YAML is a human friendly data serialization standard for all programming languages.

Ya rien de très "human friendly" dans les binaires de stockage des SGBD digne de ce nom. Et je m'en fiche que ma base postgres ne puisse s'ouvrir dans mon bloc note du moment que j'ai les moyens d'en lire/éditer le contenu dans un quelqu'onque outils et la manipulée par des bibliothèques de programmation.
Mon seul regret est qu'SQL soit nettement moins user friendly que XPATH ou XQUERY

JSON est fait pour de petit flux (bien qu'il m'arrive d'en faire de plusieurs mega) et pour être concis et directement interprétable par JavaScript (donc un outil qui à la base n'a que peut de ressources mais ça évolue) et c'est étendu à l'extérieur. je l'utilise beaucoup.
mais justement xml avec les balises ouvrante et fermante xml représente un progrès. c'est certes verbeux mais sur un flux de 1Go ou les balise on des nom de 3 char max faire la relation entre la deuxième { du json et celle qui est en plein milieu est quasi impossible } alors que mettre en relation <cli></cli> est immédiat.
j'ai beaucoup pratiqué lisp et les ((((()))(()))(()()()()()()())) pas simple de s'y retrouver
qui n'a jamais vu dans du code C java php etc. des chose comme

C'est là que l'on comprend tout à la philosophie du human friendly... Seul le parseur est censé passé son temps à lire ces salopries de flux. Pas le geek dans son bloc note.

Quand à la syntaxe que les développeurs utilises :

function test() {
...
} //end function test

Ca ne les a pas traumatisé à partir de

PROCEDURE test()
...
IF ( ) THEN

END IF;
END PROCEDURE

De toute manière, avec des ouvrants fermants, qu'ils s'agissent de parenthèses, de balise ou d'accolade; sans indexation, le tout est illisible.

pour la verbosité de XML il est vrai qu'on utilise souvent des noms longs
mais la norme n'interdit pas de faire plus court

Le problème de la verbosité n'est pas la taille des noms; mais la répétition permanente des métadonnées...

comme quoi XML permet si on le prends pour ce qu'il est de faire des choses concises rapide et qui reste bien plus lisible que

Code : Sélectionner tout
1
2
 
4F4D535F4F30350D0A313126706172610D0A312E352E3145544C0D0A

Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.

[quote]
Envoyé par bretus Voir le message
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).

Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?


Hélas, non, sinon je me tairais et me dirais : Ce n'est pas bien grave d'utiliser XML à tout va. Dès lors que tu dois échanger des flux de données "important" par un réseau, tu te retrouves vite à saturer ta bande passante grace à XML face à JSON ou du CSV-like.
Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.

Citation Envoyé par Oscar Hiboux  Voir le message
Comme 400Mo d'autres choses risquent de faire voler en éclat les parsers d'autres choses... Mais, pour décrire ces mêmes données avec un autre format, peut-être que 200 Mo suffiraient ? Voilà deux considérations distinctes.

et
Il faut savoir être pragmatique dans la vie XML n'a pas vocation à replacer tout et n'importe quoi. mais 400Mo n'est pas un pb pour XML pas plus que pour tout autre format.

Justement non. XML arrive comme seul support pour les spécifications des formats d'échanges de données. Du coup, les utilisateurs commence par exemple à exporter leurs cartes dans le format d'échange. Bilan : Des fichiers de 400 Mo sans problème.
Ensuite, il est le support des services réseaux; et pas seulement pour les requêtes où REST suffisait dans la plus part des cas; mais aussi pour les réponses à ces requêtes.
Au final, les outils se basant sur XML pullule et conduise à une utilisation déplacée car il devient quasi-incontournable pour rester dans du standard.

Mais vous avez raison : Il faut faire tourner dans le vent les machines et saturer les réseaux pour courir après le Human Readable sur le fichier/flux lui même.

Pour ma part, je trouve bien moins "idiot" d'avoir un format imbuvable, "machine readable" et les éditeurs qui vont avec...

C'est le cas avec les images et ça ne traumatise personne. L'image est stockée dans un format illisible par l'homme. L'utilisateur dispose de son lecteur/éditeur d'image. Le programmeur des specs et surtout des bibliothèques pour la manipuler.

Au rythme actuel, nous finirons par remplacer TIF et JPEG par des formats à base d'XML, plutôt que de s'inspirer de TIF et JPEG pour construire un format d'échange représentant des "objets" manipulé en P.O.O.

Alors pour en revenir à :
Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?

Il y juste ceux peut être juste ceux qui savent lire des spécifications; et ceux qui magouille dans leurs éditeurs de texte afin de décrypter les données plutôt que de lire des spécifications...

Parmi les deuxièmes, on trouve ceux qui n'ont pas compris que ce n'était pas XML qui était pratique en temps que tel, mais les bibliothèques et outils qui tournent autour... S'ils devaient se farcir l'écriture d'un parser XML, je pense qu'ils regretteraient de ne pas avoir plutôt à écrire une bibliothèque de manipulation des TIF...

bye
Avatar de thelvin thelvin - Modérateur http://www.developpez.com
le 22/04/2010 à 9:42
Citation Envoyé par bretus  Voir le message
Quand tu modifies tout fichier à lecture séquentielle, tu dois le ré-écrire dans son intégralité. Quand tu modifies un fichier où les enregistrements on une taille définie, tu peux rentabiliser "seek".

Et un tel fichier en pratique, soit est bien trop limitant, soit nécessite de réécrire le fichier quand on dépasse la "taille fixe". Ton histoire de "grand coup de balais" ne vaut pas grand-chose.

C'est là que l'on comprend tout à la philosophie du human friendly... Seul le parseur est censé passé son temps à lire ces salopries de flux. Pas le geek dans son bloc note.

Il n'y a pas de quoi être fier à ne pas voir l'intérêt qu'il soit possible de lire les flux à l'œil.

De toute manière, avec des ouvrants fermants, qu'ils s'agissent de parenthèses, de balise ou d'accolade; sans indexation, le tout est illisible.

Par exemple, le flux peut être reconstruit à la volée par des outils tiers pour le rendre lisible. En pratique c'est une question de trois touches et deux clics, et il n'y a pas eu à programmer quoi que ce soit, sans possibilité de bug.

Le problème de la verbosité n'est pas la taille des noms; mais la répétition permanente des métadonnées...

Nope. Il n'y a aucun problème avec ça.

Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.

La "flemme" est une question d'économie de temps et d'argent. Les machines sont nos esclaves, et elles peuvent nous épargner du travail sans intérêt. Donc, elles doivent le faire.

Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.

Tu oublies un peu vite qu'un flux ça se compresse et que XML a d'autres avantages que la seule lisibilité transparente... Mais je suis quand même assez d'accord, pour un échange réseau, il est plus pragmatique de se tourner d'abord vers JSON ou CSV.

Justement non. XML arrive comme seul support pour les spécifications des formats d'échanges de données. Du coup, les utilisateurs commence par exemple à exporter leurs cartes dans le format d'échange. Bilan : Des fichiers de 400 Mo sans problème.

Je maintiens que si les informaticiens ne sont pas foutus d'être des informaticiens, ce n'est pas la faute du standard de fait. Des outils pour utiliser autre chose que XML quand c'est plus adapté, on manque un petit peu, mais pas tant que ça. Et ce n'est pas la faute de XML de toute façon.

Pour ma part, je trouve bien moins "idiot" d'avoir un format imbuvable, "machine readable" et les éditeurs qui vont avec...

C'est vrai, quel intérêt de confier les problèmes récurrents aux machines et de passer à autre chose ?

C'est le cas avec les images et ça ne traumatise personne. L'image est stockée dans un format illisible par l'homme. L'utilisateur dispose de son lecteur/éditeur d'image. Le programmeur des specs et surtout des bibliothèques pour la manipuler.

Et nous savons tous qu'il y a tout autant de formats d'images que de formats de données. D'ailleurs, un brouillon de nouveau format d'image se crée en 7 minutes environ et peut être manipulé avec des outils de base standard dans les 10 minutes qui suivent. Juste un peu moins bon que XML, JSON, YAML...

Il y juste ceux peut être juste ceux qui savent lire des spécifications; et ceux qui magouille dans leurs éditeurs de texte afin de décrypter les données plutôt que de lire des spécifications...

Car les spécifications, c'est un outil qui te permet de jouer immédiatement avec les données qu'elles décrivent, sur n'importe quel environnement de travail. Et elles vérifient même que tu les as bien comprises.

S'ils devaient se farcir l'écriture d'un parser XML, je pense qu'ils regretteraient de ne pas avoir plutôt à écrire une bibliothèque de manipulation des TIF...

... Mais ils ne doivent pas. Magie !
Avatar de seb012007 seb012007 - Membre du Club http://www.developpez.com
le 29/04/2010 à 13:06
Bonjour,

Pour apporter ma pierre au troll :

Je pense que tout dépend du contexte d'utilisation du format de sérialisation des données.

Configuration de l'application :
Si on regarde du côté de symfony on se rend compte que le format yaml est dans bien des cas plus clair, moins verbeux et donc plus simple d'utilisation que le format xml. Il est aussi bien plus évolué que le fichier properties du fait de sa structure hiérarchique élaborée.
Le xml se débrouille aussi plutôt bien, c'est quand même pas la mort de lire un contrôleur Struts. Mais bon je pense que dans ce genre de cas d'utilisation la palme revient au yaml par son aspect moins verbeux dans ce genre de contexte et on gagne donc en efficacité et en aisance de développement : en clair le xml c'est pas fait pour ça, même s'il s'en sort pas trop mal.
J'ajouterai que la force de ces méthodes de travail basées sur des fichiers de configuration est quand même la propreté du code généré derrière. En clair si vous avez un développeur qui passe une semaine sur votre équipe et qu'on lui colle un contrôleur à coder, ben s'il doit se conformer à un standard pour produire du code, il a vraisemblablement moins de chance de faire un travail de cochon que si on lui donne l'occasion de coder directement.

Transfert de flux de données :
Là je vois deux concurrents, le json et le xml. Le json se retrouve souvent bien moins galère à parser qu'un xml. En python la différence est flagrante, on fait en 3 lignes avec SimpleJson ce qu'on fait en 20 avec Elementtree (+ une nouvelle classe parce que sinon c'est le bordel).
D'un autre côté à partir du moment où le flux en question peut-être lu par un humain alors on gagne beaucoup à utiliser le xml. On s'y retrouve beaucoup mieux dans les tags que dans les accolades, surtout quand on dépasse un certain nombre de ligne.
De ce point de vue j'aime bien l'approche de certaines api, par exemple celle de mediawiki qui propose les deux formats au choix. Clairement avoir un retour en xml est un plus pour l'humain, mais pour analyser le document avec un language de prog alors le retour en json est plus simple à exploiter.

Mise en forme de données :
Je comprend bien l'intérêt du xml couplé avec xsl, mais... euh... Pourquoi pas faire du html directement à ce moment là?

Bref je pense que le xml est un format tout terrain, et on peut toujours s'en sortir dans la plupart des cas avec. Il a donc l'avantage de l'universalité si on peut dire, car il est la fois compréhensible par l'humain et par la machine.
Toutefois si on regarde au cas par cas chaque utilisation on peut souvent trouver un format plus adapté. De ce point de vue j'aime beaucoup l'approche pragmatique du framework Symfony : à chaque cas précis son format. Pour un web service on utilise json, pour de la configuration on utilise yaml et pour le stockage des strings i18n on utilise du xml.

Et pour ce qui est de la présence de ce genre de formats à la place du code, comme avec Struts et Spring, moi je dis : oui oui oui! Plus on utilse ce genre de format en remplacement du code, plus le code est générique, plus il est carré, plus il est simple à maintenir. Cqfd.
Bah oui parce que dans le meilleur des mondes on peut dire qu'un bon développeur a pas besoin de ça, que son code doit être clair, lisible, bien documenté, qu'il recourt le moins possible à des verrues ou à de petites fantaisies "pour que ça passe".
En pratique dans la plupart des projets que j'ai connu les gens vont et viennent, on croise de bons développeurs comme des mauvais. L'appli, elle, reste et doit être maintenue. Il y a donc un facteur humain important qu'il ne faut jamais négliger.

Donc moins l'architecture de l'application est permissive et plus elle a de chances de rester claire et maintenable. Le fichier de configuration en lieu et place du code est fait pour ça, et moi je trouve ça plutôt bien
Avatar de thelvin thelvin - Modérateur http://www.developpez.com
le 29/04/2010 à 13:42
Pas très gras, ce troll. Et j'ai pas grand-chose à en redire, en plus.

Citation Envoyé par seb012007  Voir le message
Mise en forme de données :
Je comprend bien l'intérêt du xml couplé avec xsl, mais... euh... Pourquoi pas faire du html directement à ce moment là?

Parce que le HTML sémantique n'est pas absolument stylisable et que sa capacité sémantique est de toute façon plus limitée que celle du XML ; et que tu n'es pas sûr que tu te contenteras de ce document HTML tel quel pour toujours jusqu'à la nuit des temps.
En gros, du XML est lisible et facilement maintenable, et transformer ce XML en quoi que ce soit d'autre est facile et immédiat (à condition d'avoir appris à le faire, ce qui n'est pas long pour un informaticien. Rappel : il n'y a pas que XSL dans la vie. DOM-like et xPath for the win too.) Du HTML... Non.

Et pour ce qui est de la présence de ce genre de formats à la place du code, comme avec Struts et Spring, moi je dis : oui oui oui!

J'y mettrais une nuance : il ne s'agit pas de remplacer du code C#/Java/Python/Ruby par du code encapsulé dans du JSON/XML/YAML.
Il s'agit de remplacer du code impératif par de la configuration déclarative.
S'engager sur la première voie est encore pire. Et c'est souvent ce qui arrive quand on perd de vue l'objectif initial, ou qu'on est parti là-dedans sans raison précise.
Avatar de seb012007 seb012007 - Membre du Club http://www.developpez.com
le 29/04/2010 à 14:38
Parce que le HTML sémantique n'est pas absolument stylisable et que sa capacité sémantique est de toute façon plus limitée que celle du XML ; et que tu n'es pas sûr que tu te contenteras de ce document HTML tel quel pour toujours jusqu'à la nuit des temps.

J'avais pas vu ça comme ça. En effet, le champ d'application est plus vaste qu'avec du html dans ce cas.

J'y mettrais une nuance : il ne s'agit pas de remplacer du code C#/Java/Python/Ruby par du code encapsulé dans du JSON/XML/YAML.
Il s'agit de remplacer du code impératif par de la configuration déclarative.

Absolument. De toute façon c'est comme tout, chaque solution a un domaine d'application propre. C'est un peu comme vouloir générer une application entière en uml en espérant ne jamais avoir à coder une seule ligne, c'est une illusion.

Le tout est donc de déterminer en fonction de la situation si on a besoin de code, de json, de xml etc.. L'idéal étant d'obtenir à un instant T avec les outils disponibles à cet instant le juste équilibre entre performance et lisibilité/maintenabilité.

Un numéro d'équilibriste en somme.
Offres d'emploi IT
Lead dev backend java web - h/f
UpSourcing - Ile de France - Paris (75000)
Développeur java web open-source H/F
Atos - Ile de France - Issy-les-Moulineaux (92130)
Lead dev backend java web - H/F
UpSourcing - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java Web : Mickael Baron - Robin56 -