Discussion :

[FloMo]

Simple question ? Existe-t-il un système de description d'un format Json ?
De spécifier quel champs sont obligatoire, présent, si il sont de type alphanumérique, numérique, devant correspondre à un pattern ou à une liste de valeur possible ?

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

[Paul TOTH]

Tout dépend, dans ton cas. Si les modifications ne sont pas faites directement dans le fichier lui-même (via une interface de ton logiciel) ou alors uniquement par des personnes compétentes, alors le XML peut faire l'affaire tout comme les autres formats. Si le fichier peut directement être modifié, pourquoi pas par des personnes pas forcéments compétentes (client en télémaintenance par exemple) il est clair que le fichier ini est plus pratique à mon gout.


Ca c'est l'idée qu'à tenter de lancer Microsoft avec la sortie de Windows 98 et l'abandon du format ini (déclaré définitivement obsolète à ce moment là) au profit dans un premier temps de la base de registre puis du format xml présenté comme le remplaçant du format ini.
12 ans plus tard, le format ini existe toujours, les api de gestion de ce format sont toujours présentes dans Windows y compris dans W7, et même Microsoft lui-même continu de l'utiliser en 2010.
Comme quoi, si le format ini est probablement plus limité que le xlm, il est encore nettement suffisant et pratique pour toujours exister.

XML est une hérésie

enfin non pas tout à fait, il est éventuellement utile pour transférer des informations d'un système à un autre...mais je m'en suis toujours sortie avec d du format texte !

un fichier de paramètre n'a pas vocation à priori à être transféré d'une appli à une autre ... donc son format interne importe vraiment peu. Et s'il doit être humainement lisible, je ne choisirais certainement pas le XML !

XML est "difficile" à parser, n'est pas prévu pour les mises à jour, du coup son utilisation dynamique implique d'énormes consommation mémoire pour des performance acceptables...tout cela ... pour RIEN ! Aucun gain par rapport à un format INI ou propriétaire...c'est tout de même incroyable qu'on l'utilise à tour de bras !

En fait je pense qu'il s'est imposé par l'éternel "j'ai une lib qui fait tout ce qu'il faut pour traiter le XML"...donc on ne veux plus savoir ce qu'il se passe en dessous, qu'importe s'il faut installer .Net et je ne sais quelle extension ou composant...moi j'ai plus rien à faire dans mon programme

[benzoben]

Pour moi l'intérêt du XML vient surtout des schemas/DTD qui permettent de valider un document et de connaitre "facilement" les règles de validation.
Avec un fichier ini ou properties, on est lié aux eventuels commentaires présents dans le fichier en espérant qu'ils seront exhaustif.

Maintenant, la complexité du format ne vient elle pas surtout des API de parsing qui sont je trouve assez lourde quand on veut faire des choses simples.

[Hikage]

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

Merci pour l'information. Je ne connaissais pas

[aurelman]

Bonjour,

J'y vais de ma petite réponse.

Disons le clairement, mettre XML partout et pour tout, ne semble pas nécessaire.
De plus, il y a eu une époque où mettre du XML c'était "in". Alors on l'a fait et on en a mis partout.

Seulement à la base, XML de part sa conception simple et son aspect structuré, a été conçue pour permettre l'échange d'informations de manière interopérable entre des composants logiciels différents.

Aujourd'hui, il est utilisé en tant que "configurateur" ou pour donner des directives à un logiciel/outil/programme. Bien loin de ce pour quoi il était prévu en somme...

Mais XML n'est pas si "human-readable" qu'on le dit... pire que ça, il est très verbeux !!

Ainsi pour configurer :
Pourquoi ne pas préférer des syntaxes plus concise, plus user-friendly :
Properties quand une structure élaborée n'est pas nécessaire, YAML pour des choses plus poussées...(autre)
Pour donner des directives à un programme et que celles-ci ne sont pas destinées à être modifiées tout le temps : pourquoi pas les annotations lorsque le langage utilisé le permet.

Alors : XML : oui ! Partout : non !

[vintz72]

XML n'est pas mauvais en soi. Mais je suis 100% d'accord pour dire qu'il est souvent utilisé à tord et à travers. Pourquoi utiliser par exemple XML pour définir sa config log4j alors qu'on y arrive très bien (et même de façon plus lisible au final) avec un fichier properties ?

Le défaut d'XML est sa verbosité. Eplucher un pom.xml est souvent fastidieux. Je pense qu'un bon éditeur XML peut compenser la plupart de ses défauts, mais même Eclipse a du mal : chez moi, selon l'heure de la journée, le fichier édité et que sais-je encore, la complétion automatique ne marche souvent pas...

Quant aux remplaçants potentiels : JSON => j'aime pas du tout la syntaxe, je trouve que c'est aussi lourd que XML (avec des { " en pagaille, beurk.
YAML => ça a l'air mieux, une sorte de .properties évolué. Mais il faut s'y faire.

[Bryce de Mouriès]

Je trouve ça très pratique pour transférer des données d'un langage à l'autre, un script PHP qui génère un xml pour ensuite l'envoyer à Flash. C'est pratique pour l'échange grâce à la structure que l'on donne aux données et à la sémantique que l'on peut apporter. Un texte n'est alors plus simplement un texte sans signification pour l'ordinateur, selon la balise utilisé cela devient un titre, un descriptif, un paragraphe etc..

Je suis étonné de voir que certain l'écrive à la mano sans XSD/DTD Oo, ça semble se limiter pour les configurations, il vaudrait peut être mieux oublier ce format pour ce domaine ou proposer systématiquement une génération à partir d'une interface (ça n'a rien de compliqué de générer du xml)

C'est moche le JSON :p, c'est vrai que c'est plus léger par contre !

[mrjay42]

Moi ce qui me gène ce n'est pas seulement l'utilisation abusive qui est faite de XML.

Je crois que ce qui me gène le plus, c'est XSL.
Un langage de balise chargé de faire des traitements, allègrement saupoudré d'un langage de requetage (xPath) qui lui n'est pas un langage de balise...

[Paul TOTH]

XML n'est pas mauvais en soi. Mais je suis 100% d'accord pour dire qu'il est souvent utilisé à tord et à travers. Pourquoi utiliser par exemple XML pour définir sa config log4j alors qu'on y arrive très bien (et même de façon plus lisible au final) avec un fichier properties ?

Le défaut d'XML est sa verbosité. Eplucher un pom.xml est souvent fastidieux. Je pense qu'un bon éditeur XML peut compenser la plupart de ses défauts, mais même Eclipse a du mal : chez moi, selon l'heure de la journée, le fichier édité et que sais-je encore, la complétion automatique ne marche souvent pas...

Quant aux remplaçants potentiels : JSON => j'aime pas du tout la syntaxe, je trouve que c'est aussi lourd que XML (avec des { " en pagaille, beurk.
YAML => ça a l'air mieux, une sorte de .properties évolué. Mais il faut s'y faire.

JSON comme XML a un intérêt...c'est qu'il est natif Javascript...en ce sens ce n'est pour moi pas réellement un format de fichier mais une syntaxe de langage...qui n'a d'intérêt que si on bosse en Javascript.

C'est un peu comme si on disait qu'il faut utiliser le Pascal pour son fichier de config

Code pascal :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// configuration serveur
type
  TConfig = record
    Version : Integer;
    MaxClients: Integer;
    ServerAddr: string;
  end;
const
  Config : TConfig = (
    Version : 1;
    MaxClients: 12;
    ServerAddr  : 'localhost';
  );

ah ben tient, je viens d'inventer un nouveau format de fichier auto documenté

[nicorama]

Le problème de Struts est structurel. Si sa configuration était faite en JSON ou en .properties, le problème serait exactement le même : imbuvable au delà de 50 lignes.
De même pour le web.xml en java

Personnellement, je préfère échanger dans mes requêtes HTTP du XML que du JSON, car je le trouve plus lisible lors du debugage mais c'est kif-kif. Changer l'un pour l'autre n'apporte pas une révolution technologique.

JSON prend moins de place, mais en utilisant en production le gzip, on arrive à la même taille pour l'un et l'autre, à une cacahuette près. En pratique, on utilise presque jamais gzip, car c'est rarement (jamais !) le facteur limitant des performances.

Enfin XML par rapport à JSON ou surtout les .properties apporte une structure plus complexe en cas de besoin. Essayez de faire une page web en .properties...

Bref, trop de XML tue le XML, mais c'est le problème de l'ingénieur/architecte, pas la faute du "langage" en lui-même.

[Traroth2]

Je trouve le YAML parfaitement imbuvable à côté de l'XML. Ce truc est une vraie horreur, et n'est clairement pas si lisible que ca. A force de vouloir simplifier les structures, on en perd justement en lisibilité. Bref, perso, XML ne me dérange pas du tout.

Personnellement, je n'ai jamais eu de problème à lire et à modifier du XML à la main, même si je peux facilement imaginer des occupations plus amusantes...

Là où XML me dérange, c'est quand il remplace du code, en Java par exemple. Si on utilise des outils comme Maven, Spring ou Hibernate (ou iBatis, d'ailleurs), on finit par gérer plus de XML que de Java, et là, c'est gênant car on finit par se perdre dans la multiplicité des fichiers source (parce que finalement, ça veut bien dire qu'on a des sources en XML) dont il faut connaitre le contenu et la syntaxe spécifique, qu'il faut modifier, tester, mettre en production, etc. Les annotations sont là un progrès très net.

[yann2]

salut

Le problème de Struts est structurel. Si sa configuration était faite en JSON ou en .properties, le problème serait exactement le même : imbuvable au delà de 50 lignes.
De même pour le web.xml en java

Correct ! Toutefois, allez taper à la main dans ces fichiers de configuration est quand même un problème. Avoir une interface graphique jolie et intégrée dans un bon IDE avec validation (et qui te dis si la classe Action ou le Form existe) est déjà un gros plus. En fait, tout sauf avoir à aller fouiner dans ce fichier indigeste. Ça existe certainement (du moins je l'espère) mais, de mon côté, on n'utilisait pas un tel outil lorsque je faisais du dev JEE.

J'ai toujours penser qu'un fichier XML ne doit pas être saisie à la main mais :

* être généré
* offrir une interface graphique permettant de visualiser/éditer le fichier xml

yann

[_skip]

Les technos java sont malheureusement très friandes de XML, si on regarde JSF, c'est une atrocité de la guerre en la matière, avec sa syntaxe proche de JSP. Mais le plus impardonnable c'est d'avoir en sus de la configuration servlet/filtre déjà lourdingue, ajouté ce fichier "faces-config.xml" pour des raisons de flexibilité mais qui finit par alourdir à mort.

Heureusemnent il existe différentes solutions alternatives, actuellement j'utilise wicket et son XML minimum est vraiment rafraîchissant. Par exemple la config se fait en java.

Code java :

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
public class ZenContactApplication extends WebApplication {
 
@Override
public Class getHomePage() 
{
     return MyWelcomePage.class;
}
 
@Override
public String getConfigurationType()
{
    return DEVELOPMENT;
    //return DEPLOYMENT;
}
//(...)
}

et une redirection se fait par :

Code java :

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

1
2
 
setResponsePage(MyNextPage.class);

Quand même un bon point, en JSF 2.0 il semble que les annotations tendent à remplacer ces configurations XML totalement vides de sens pour une certaine partie.

[sennomo]

(lisp)

[X0000]

ça fait du bien de se lire qu'on n'est pas le seul con sur terre à se dire qu'il y a eu de l'abus . Vive le fichier .ini et autre JSON.

[Erwy]

Un petit point sur le coté "illisible" du XML.

Comme n'importe quelle source de données un fichier XML doit respecter des formalisme par rapport au données stockées, exactement comme une base de données relationnelle correcte respecte les formes normales pour être utilisable.
Hors un bon nombre de développeurs, en particulier d'API java, "code" le XML comme des porcs (et malheureusement il font souvent la même chose quand on leur file une base de donnée...)

Le problème vient pour moi d'une culture actuelle très axé sur le développement applicatif et qui néglige fortement l'axe donnée avec souvent une vision tout "objet" alors qu'une source de données est bien plus qu'une collection d'objet.

Qui parmi les personnes présentes ici a jamais pris la peine de se renseigner ou au minimum de réfléchir sur le formalisme des données d'un XML avant de pondre une structure de donnée sous ce format ?

[camboui]

Rien de tel que ce bon vieux INI.

[petrone]

j'utilise wicket et son XML minimum est vraiment rafraîchissant. Par exemple la config se fait en java.

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).

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.

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.

La question de la "qualite" du XML par rapport a JSON ou un fichier texte plat ne se pose pas. Tous ceux qui ont eu a gerer des flux de donnees en format csv ou autres savent apprecier les apports du XML et des schemas.

Mais XML n'est qu'un outil et le resultat depend de l'usage qui en est fait.

[mioux]

Perso, j'ai toujours trouvé le XML stupide pour de la configuration simple (ce que j'appelle simple, c'est quand on n'utilise que des chaines de caractères, des entiers, bref, des types de base quoi). C'est s'encombrer de balises qui ne servent à rien pour faire la même chose qu'aurait pu faire un fichier ini.

Il est (toujours selon moi) utile d'utiliser du XML quand on a des gros volumes de données à transférer/stocker car la recherche et la modification est simplifiée par les API qui existent. En revanche, il en devient illisible par un humain.

Il a des mécanisme de contrôle (ce qui est plutôt pratique) permettant d'obtenir un résultat cohérent, évitant ainsi des erreurs lors des transferts de données.

Il peut porter des objets très complexes contrairement à certaines autres techno (JSon par exemple ne sais pas gérer nativement des données octales, ça peut paraître con, mais pour gérer des droits d'accès sur des systèmes de fichiers EXT, c'est dommage)

Il permet de créer des applications interportables plus facilement, puisque très documenté et analysable à l'œil facilement (pour le reverse engineering).

En revanche, il est d'une lenteur sans nom face à d'autres technos...

Et je pense que comme dit, on nous l'a servi à tellement de sauces qu'aujourd'hui, tout le monde en est écœuré.

En bref, c'est une bonne techno, mais il faut savoir quand et comment l'utiliser

[Cyrilange]

En tant que développeur .NET je pense que l'XML ne doit être utilisé que pour l'interopérabilité et le polymorphisme d'objets stockés dans une base de données.

Pour ce qui est des fichiers de configuration, cela peut vite devenir un vrai casse tête avec des problème de syntax, de "case sensitive" et de bric à brac de sous ensembles et de propriétés anarchiques.

Bref, XML c'est bien, mais pas à toutes les sauces.