Pour structurer un document , ok , pour des données pas trop grosses, c'est plus lisible qu'un .CSV
Mais pour faire du HTML, je ne vois pas l'intéret de fabriquer du XML au lieu de directement fabriquer du HTML via PHP
Je sais, on va me dire que ta page doit être réécrite pour faire du mobile ou pour imprimer ... Combien de cas ? Mes clients ont tous un browser qui cause 1024*768 et le CSS me suffit largement
Enfin, je pose la question et vu l'affluence de ce forum, XML ne s'impose pas encore vraiment !

Dans mon cas, je ne vois pour l'instant qu'un seul intérêt pour lequel j'utiliserais XML : permettre aux autres d'accéder à des infos grâce aux agrégateurs.

Et puis ici c'est PHPFrance donc voir plus de gens utiliser du XML que du PHP me paraîtrait étrange

Ne pas confondre XML et PHP.

XML est un langage de structure de données et PHP est un langage dynamique qui permet de générer toutes sortes de format de données (incluant XML)

Cependant, avec un format universel (XML) on peut générer tous les formats imaginables : HTML, PDF, ebook, rtf, Word, etc.

Donc il ne faut pas créer de faux débât en affirmant que XML est meilleur que PHP ou inversement car ce sont deux langages différents et réponds à des besoins différents.

la puissance du langage de balise XML c'est qu'il est extrement souple et facile a mettre en ouevre notament pour tous ce qui est echanges de données et web services .... mais il faudra toujours un un php ou un asp derriere pour le traitement de ces dites informations

Mon propos initial n'était pas de comparer PHP et XML mais
certains développeurs et non des moindres parlent de XML comme très souple (why not ?)
A ce jour, mes expériences se limitent à :
- XML à la place d'un .CSV , c'est good
- XML à la place d'une table SQL, sur 200 lignes, c'est plus simple
- mais XML pour remplacer du HTML c'est très lourd car XHTML (pour être plus précis) impose de revoir tout son code (HTML/CSS) à zéro

par contre, XMLRAD chez DEVELOPPEZ ne parle que de cela et considère le XML comme le coeur de son système ...

A suivre ...

Pour moi le XML c'est de la poudre aux yeux. La seule valeur ajoutée que je vois au XML c'est la partie "encoding" au début du document qui permet de s'assurer d'avoir de quoi lire correctement les caractères...
Sinon globalement ça n'a rien de révolutionnaire, c'est vaguement une généralisation d'un truc que tout le monde fait depuis que la programmation existe et qu'on s'est dit que stocker les données sur un fichier c'était bien: on choisit une structure de fichier, et on s'y tient. XML c'est ça. Il a le mérite d'avoir une structure suffisamment extensible pour qu'on puisse l'utiliser pour toute donnée.

Je suis généralement très agacé dès que j'entends parler de XML, parce que ce truc n'apporte finalement pas grand-chose, et trop souvent il ne sert que d'argument commercial. "Programme compatible XML" youpi ! On achète ! Et tous les gogo qui n'y connaissent pas grand-chose mais pensent s'y connaître (et il y en a un paquet, et ce sont parfois des décideurs) tombent dans le panneau...

Bref, dommage, une très bonne idée, un concept très utile qui a permis beaucoup de standardisation, mais trop utilisée comme un argument bidon.

Sans rentrer en guerre, je partage le point de vue de Naholyr.

Pour moi, le XML, c'est du CSV amélioré.
Cela en garde les avantages :
- légèreté
- compatibilité
- rigueur de la construction
et en ajoute d'autes :
- meilleure lisibilité à l'oeil nu
- enrichessement de la mise en forme
- exploitation web

Mais :
- cela n'a rien de révolutionnaire. C'est une amélioration, un perfectionnement.
- au stockage de données sur fichiers, je continue de préférer les SGBD.

Je ne critique pas l'intérêt technique. Au contraire !
Je mets en garde contre l'effet de mode.

HS : On rencontre des abus semblables avec Java.
De nombreuses offres d'emploi exigent des compétences Java.
Voulant comprendre les raisons d'un tel engouement, j'ai appelé plusieurs de ces boîtes.
9 fois sur 10, leurs projets étaient réalisables en PHP.
"Oui, mais on préfère le faire en Java parce que... euh... Ben, c'est mieux, non ?"
Sans commentaires.

- mais XML pour remplacer du HTML c'est très lourd car XHTML (pour être plus précis) impose de revoir tout son code (HTML/CSS) à zéro ...

Il est certain que tous ceux qui ont fait des sites à la grande époque de la bulle Internet où tout le monde et n'importe qui s'est mis à faire des sites n'importe comment du moment que c'était joli se retrouvent aujourd'hui avec un problème majeur sur les bras : un code mal torché même pour du html. Or effectivement, le XHTML a la rigueur du XML et n'accepte pas les fantaisies.

Mais qu'on se rassure, il existe des outils pour automatiser le processus dont un fourni par le W3C si je ne m'abuse. Où est le problème: on aura dans l'avenir des sites plus conformes aux standards, les éditeurs de navigateurs pourront de plus en plus nous faire des logiciels qui lisent ces pages sans devoir faire des pirouettes pour tolérer et afficher quand même des bafouillages dans le code.

Quant au problème XHTML/CSS, je trouve que c'est une bonne chose. On sépare la structure de la mise en page, ça laisse à mon avis la liberté au graphiste de pouvoir proposer à son client une (fausse) refonte de l'interface juste en refaisant une feuille de style : si le site a 200 pages, il n'en refera pour autant aucune, refaisant une feuille de style. L'exemple le plus spectaculaire en la matière est csszengarden : plus de 150 mises en page différentes pour strictement le même contenu.

Vous parlez beaucoup du XML comme d'un lagage à aprt entière puisque vous le comparez au PHP et à l'HTML !!!

A l'origine, le XML a été formé pour transporter des flux d'informations !!! Les dtd ont été ajoutée afin de valider le contenu et les feuilles de styles xsd et autres .sd ont été ajoutée afin d'éviter de construire du HTML à partir du PHP, ASP ou autre langage de script, mais directement depuis une feuille de style !!!

Le XML ne peut pas être un unique language de dev !!! Du moins, pas à mon gout !!! De plus, même si le XML sert à stocker des données, en cas de gros volume de données, les tailles, performances comperées tourneront toujours à l'avantage des SGBD puisque le XML est avant tout un fichier texte !!!

Je trouvais aussi que ca ne servait à rien jusqu'au jour où j'ai commencé à utiliser XML en interaction avec Flash d'un côté (affichage évidemment) et php de l'autre (écriture de fichiers) et c'est assez incroyable ce que l'un peu faire en terme de contenu dynamique sous Flash (car sinon, quelle galère !).
Sinon, pas mal de possibilités également avec .net et ses DataTables, je pense que c'est plutôt que dans le contexte des développeurs php, ca n'a pas trop d'utilité, mais c'est vraiment pratique dans énormément d'autres contextes.

c'était ma petite contribution

...c'était ma petite contribution

Grosse contribution qui montre par l'exemple l'utilité majeure de XML : les flux de données dans un format utilisable par des technologies disparates voire incompatibles : c'est quand même le but de XML.

...c'était ma petite contribution

Grosse contribution qui montre par l'exemple l'utilité majeure de XML : les flux de données dans un format utilisable par des technologies disparates voire incompatibles : c'est quand même le but de XML.

C'est le but de n'importe quel format ouvert. C'est donc en ça que je critique XML (en tous cas le tapage qui est fait autour) c'est qu'on présente ça comme la solution ultime, alors que n'importe quel format du moment qu'il est ouvert est tout aussi adapté. L'interopérabilité ce n'est pas une question de XML, mais d'ouverture de format

Oui naholyr, et non: dans un sens, si toute la planète fait un consensus autour d'un langage unique d'échange de données, ne crois-tu pas que ça va faciliter la vie de pas mal de développeurs ? On peut en effet utiliser d'autres formats ouverts, mais le fait que XML fasse l'unanimité parmi la plupart des acteurs majeurs ne peut que finalement bénéficier à tout le monde. Enfin c'est un avis personnel.

Ce n'est pas un langage unique d'échange de données
Quand une appli "parle xml" il est a priori impossible de deviner pour autant la structure finale des fichiers : noms des balises, structure globale, etc...

Une DTD est illisible, on doit donc de toute façon documenter son format qu'il soit en xml ou autre si on veut qu'il soit utilisable. Donc entre un format ouvert et documenté, et un format ouvert et documenté basé sur xml, je ne vois que peu de différence si ce n'est que :
- XML a une structure maintenant reconnue, et donc plus facile à s'approprier
- XML est d'une lourdeur importante, et l'utiliser pour des données transitant souvent sur un réseau me parait un assez mauvais choix (mais je dois me tromper, car ce choix a été fait pour les web services, ou comment envoyer 25Ko de données pour un paramètre numérique).

...c'était ma petite contribution

Grosse contribution qui montre par l'exemple l'utilité majeure de XML : les flux de données dans un format utilisable par des technologies disparates voire incompatibles : c'est quand même le but de XML.

Un autre aspect, à mon sens est le suivant : Jusqu'à xml, les données pouvaient être lues par des machines ou des humains, rarement les deux à la fois. (les cartes perforées, les bandes magnétiques, les fichiers binaires, les fichiers séquentiels, les fichiers dbf, word, excel etc..

En fait, l'humain sait lire la chose écrite, mais les machines, non. Elles lisent du binaire sous réserve de connaitre la structure, mais ne savent même pas distinguer le couplet d'un refrain d'une chanson des Beatles.
Xml apporte une nouvelle dimension. Il est possible de comprendre ce que le fichier contient, et comment l'information est organisée.
Pour les machines et les programmes, c'est encore plus simple. Pas très difficile d'analyser un fichier xml avec php5.

Les applications de XML sont infinies :
Pour les bases de données, offre une alternative aux bases sql ou autres, particulièrement adapté aux fichiers de petite et moyenne taille. Pour l'analyste, on se plait à réver à des tables évoluant dans le temps sans mettre à plat leur structure, acceptant sans problème l'ajout d'une propriété en fonction des (nouveaux) besoins... La nature arborescente de xml l'y autorise.
Pour les scientifiques, le codage xml des formules mathématique permet leur visualisation et leur représentation, comme avant avec tex, latex, mais permet de plus de maintenir la formule sous une forme active, c'est à dire qu'un programme de calcul pourra manipuler l'objet mathématique... (mathml)
Pour le designer WEB, la parfaite séparation du contenu et de sa présentation permet d'enrichir l'un et l'autre, en tout cas jamais au détriment de l'un par rapport à l'autre.
Xml est aussi d'un grand secours pour rédiger des mémos, des manuels, de la documentation...
Pour l'analyste programmeur, le concept xml accompagne de très près les notions de données, méta-données et méta-méta-données et il est étonnant d'imaginer ce qu'on peut faire avec une structure d'objet codé en xml, sachant qu'un transformateur pourra en déduire son formalisme UML, sa documentation html ou pdf, et en cherchant un peu, son codage php, java, c++ ou d'autres langages à venir.
Les enjeux et l'intérêt xml résident par là...

Les défauts de xml résident aujourd'hui dans sa jeunesse, ou sa précocité: les fichiers xml sont "verbeux", mais l'embompoint en taille s'estompe avec une bonne compression de données. D'ailleurs les fichiers Open Office sont codés en XML, et simplement zippés sous un autre nom. A l'intérieur, les données de traitement de texte, du tableur, sont lisible par l'humain, et par le programme qui voudra bien s'y pencher.
Xml est au centre d'une petite galaxie de sigles (xsl, xpath, xforms, xquery...) dont la première aproche est particulièrement indigeste. Surtout xsl qui romp avec les habitudes de codage procédural ou objet.
Mais un fois qu'on a cassé la glace, alors l'imagination reprend un coup de fouet, et les moyens sont réellement décuplés.

Voilà, mais je pourrais en parler des heures...