On en parle de plus en plus, je me suis donc mis à lire un peu de doc. Mais y a quelque chose que je pige pas, quel est l'interet du xml ? On peut définir ses propres balises ce qui revient a définir son propre format de fichier, donc utilisable uniquement par l'application utilisant ces fichiers. Donc quel est l'avantage par rapport à un format proprio ?
 
Bon j'ai certainement rien compris comme d'ab    
Merci de m'éclairer.

Ce sujet m'intéresse, je suis curieux de voir les réponses.
 

L'intérêt c'est que la façon d'écrire les balises et de les définir est standard

En bref, j'dirais que c un standard pour la description de données.

Son avantage est que justement, ce n'est pas un format proprio. Il est normalisé, les specs sont publiques. De plus il existe de très nombreux outils pour générer/manipuler du XML. Bref utiliser XML, c'est gagner du temps (on utilise les outils existants), et c'est s'assurer que tes fichiers seront toujours "compréhensibles" (par le caractère public du XML).
 
Après, il faut voir tes besoins. On a pas forcément besoin d'utiliser XML partout. Pour faire un simple fichier de configuration pour une appli c'est peut être lourd. Si c'est pour gérer toute une chaine d'information (avec sortie XHTML par ex), là  le XML est tout indiqué.

Moi je pense que le XML est très pratique dans le cas d'applications faisant appel à des données ne nécessitant pas la mise en place d'un SGBD lourd (cas de bases très petites par exemple).
 
Par contre, pour les fichiers de config des softs, je lis partout qu'un fichier XML est parfait, mais en quoi un tel fichier est plus pratique qu'un fichier INI par exemple ? Personnellement, je trouve que parser un fichier *.ini est bien plus pratique pour lire des infos de config d'un soft qu''un fichier XML, nécessitant l'intégration d'un parseur + ou - lourd, etc...
 
Les puristes me répondront que ça facilite la portabilité, mais dans le cas d'un soft écrit uniquement pour un OS, le XML n'est il pas un peu trop lourd pour un simple fichier de config ?

pour INI vs XML, je préfère le INI, mais dans certains cas il est trop limité
quand tu as besoin de listes de valeurs qui elles-mêmes sont constrituées de listes, c'est vachement plus clair de le faire en XML.
Pour le poids du parser, c'est pas si gros que ça (du moins celui que j'utilise en Delphi)

Je vais peut-être me faire taper dessus mais XML est aussi très pratique pour permettre à des applis client/serveur de discuter entre elles tout en passant les firewalls.
Exemple : on a un client qui a des infos qu'il aimerait faire traiter par le serveur. Bin plutôt que de définir un protocole propriétaire qui demanderait à l'admin système d'ouvrir des ports sur le firewall (cf CORBA), on écrit les données dans un XML et on envoie le tout à une servlet via une requête HTTP. C'est simple, y a pas de complications au niveau réseau et c'est standardisé. Et en plus y a des parseurs très bien qui font le boulot d'extraction des données.
Ca c'est un premier cas d'utilisation mais sinon, j'ai fait un stage y a 3 ans où le but était d'exporter une base ou une config Tivoli (NB : non, c'est pas une base de données, du moins pas à l'époque puisque je sais pas comment ça a évolué depuis) vers un fichier persistant. Bon ba XML s'est révélé très adapté pour ça, non seulement de par son format mais aussi grâce aux multiplies outils qui existent à côté et les nombreuses utilisations possibles (transformation XSL, par exemple).

 
C'est plutot HTTP qui est pratique pour ça. Le fait que l'on utilise du XML pour ça est plus lié au fait que ce soit simple à manipuler

 
Ui, mais pour moi ça reste lié. Tu peux tout à fait développer ta propre syntaxe de messages mais ça prendra beaucoup de temps à créer et à maintenir pour obtenir au final un truc qui ne sera pas standard. XML a permis l'essor et la généralisation de telles techniques grâce à son aspect rigoureux au niveau de la syntaxe mais comme en plus c'est un standard, beaucoup d'applis permettent de faciliter la tâche au développeur.
Donc oui, pour le transport HTTP c'est bien mais encore faut-il avoir un système de messages qui tienne la route et c'est là tout l'intérêt d'XML (à mon sens).

 
Un message étant un ensemble de données structurées, ce que tu dit pour un message est vrai pour tout ensemble de données structurées. Le message est juste un cas particulier

Bon ce que je retiens pour l'instant c'est que xml c'est bien car y a des outils pour parser les fichiers et que y a pas besoin de se taper de docs spécifiques parce que c'est normalisé.
 
mouais...

 
Pas juste parser, mais également les manipuler pour les transformer (XSL/T), faire des requêtes dessus (XPath/XQuery), les mettre en forme pour les afficher (CSS), les liers entre eux (XLink).
 
 
 

etrange... un oubli ?

 
Justement pour les afficher, ca peut le faire sur n'importe quel fichier xml ?

Tiens, chocoboy n'a pas encore débarqué? Ca m'étonne

 
SOAP powa

je me posais la même question
edit: en tout cas il est actif, son dernier post date d'il y a une minute

le XML c'est pour faire pro devant les clients

 

 
Enorme avantage pour ma part quand on utilise un fichier XML pour y stocker des données pour un programme (donc un fichier de record) c'est le jour ou tu veux rajouter ou modifier un champ dans ton record, si c'est un fichier binaire tu vas pleurer, si c'est un fichier XML ca t'aura pris 3s.
 
De plus pour les options c'est pas vachement plus lourd que les INI, j'ai interfacé mon parser avec une petite classe pour les options et j'y accède comme si de rien n'était avec des valeurs par défaut si la branche existe pas ou si le fichier est bousillé...
 
Et encore un autre avantage (avec le premier) c'est que si tu fais un programme un tant soit peu connu, un mec qui a envie de récupérer les données du fichier pour les utiliser dans un script PHP ou même dans OpenOffice (ou exel ), il pourra le faire en quelques secondes sans t'emmerder pour savoir comment tu stoques les données ou sans devoir implémenter un truc pour en extraire ce qu'il demande... bref... le pied pour les users qui développent un peu    
 
Sinon y a un truc que tu sais pas représenter dans un INI (du moins pas aussi facilement) c'est une jolie architecture en arbre. J'utilise ca et franchement ca change la vie, même pour un fichier d'options (c'est une plaie avec un INI).
 
Ah oué, c'est aussi géant pour des fichiers de traduction, j'y ai gagné pas mal en perf (sisi) en utilisant du XML plutot qu'un ini ou un autre truc