"Le problème que le XML résout n'est pas difficile, et il ne le résout pas bien"
Que manque-t-il le plus au langage ?
Le 2012-08-27 17:05:22, par Hinault Romaric, Responsable .NET
Normalisé par le W3C, le langage XML (Extensible Markup Language) a été largement adopté comme format d’échange de données entre différents systèmes, plateformes et organisations.
Mais, le langage a quelques faiblesses qui font souvent l’objet de plusieurs discussions et de rejet par certains. « The Essence Of Xml », l’un des documents fondamentaux sur le langage écrit par Philip Wadler et Jérôme Siméon procède à une analyse de celui-ci.
Selon le document, les deux propriétés clés nécessaires pour n’importe quel format sont les suivants :
Pour les auteurs du document, un exemple de format de données avec ces deux propriétés est Lisp EssExpressions (expressions symboliques de la communauté de développeurs Lisp), et XML est loin d’implémenter correctement celles-ci.
Selon Walder et Siméon, l’essence du XML se résume simplement à : « le problème qu’il résout n’est pas difficile et il ne le résout pas bien ».
Source : The Essence Of Xml (au format PDF)
Et vous ?
Êtes-vous d’accord avec cette conclusion ?
Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?
Quelle est l’essence du XML pour vous ?
Mais, le langage a quelques faiblesses qui font souvent l’objet de plusieurs discussions et de rejet par certains. « The Essence Of Xml », l’un des documents fondamentaux sur le langage écrit par Philip Wadler et Jérôme Siméon procède à une analyse de celui-ci.
Selon le document, les deux propriétés clés nécessaires pour n’importe quel format sont les suivants :
- self describing : le document XML devrait être suffisant pour obtenir les données sans ambigüité ;
- round tripping : la conversion de la représentation interne des données dans un logiciel (comme un objet à l’intérieur d’une application Java, des structures dans une solution C, des lignes d’une table Oracle, etc.) au format XML et vice-versa, devrait produire les mêmes données. En d’autres termes : data == DecodeFromXML(EncodeToXML(data)).
Pour les auteurs du document, un exemple de format de données avec ces deux propriétés est Lisp EssExpressions (expressions symboliques de la communauté de développeurs Lisp), et XML est loin d’implémenter correctement celles-ci.
Selon Walder et Siméon, l’essence du XML se résume simplement à : « le problème qu’il résout n’est pas difficile et il ne le résout pas bien ».
Source : The Essence Of Xml (au format PDF)
Et vous ?
-
_skipExpert éminentJe suis d'accord avec kolodz sur le fond, surtout sur l'aspect des utilisateurs sérieux. Mon entreprise demande un fichier XML aux clients, tout est mis à disposition pour bien faire : un schéma xsd, un service de validation en ligne et pourtant 80% des utilisateurs (majoritairement des développeurs web) nous sortent un fichier mal formé au premier essai.
Les erreurs type sont les suivantes :
- Mauvais encodage des &
- Utilisation d'entité html dans le contenu
- UTF-8 dans l'entête alors que ce c'est du ISO8859.
- Non respect des séquence d'apparition
Le problème étant que plein de gens se contentent d'écrire du
string += "<element>" + value + </element>
sans penser que ça leur sauterait à la figure, car un fichier xml avec une dizaine d'éléments, ça paraît très simple à fabriquer or c'est un format exigeant.
Enfin ceci mis à part, tout n'est pas rose côté XML. Si je reprend les arguments.self describing : le document XML devrait être suffisant pour obtenir les données sans ambigüité ;
Du style- Ah flûte, je savais pas que l'élément catégory était facultatif
- Ah flûte, je savais pas que lorsqu'il n'y avait pas de prix on mettait N/A comme valeur
- Ah tiens, cet élément est présent mais vide (""
, ça veut dire null?
Et il faut qu'après 2-3 semaines sans soucis on ait un gros plantage de l'importation parce que ce qu'on a pas pu imaginer arrive.
Les outils pour pallier à ça sont les schémas. Manque de pot ils exigent de voir dans le fichier final leurs préfixes sur lesquels tous les parseurs avec lesquels j'ai travaillés sont impitoyables, ce sont des fichiers externes et franchement, ils sont souvent juste 10x trop complexes pour ce qu'on voudrait leur faire faire.
Les schémas me donnent l'impression d'être parti d'une très bonne idée puis d'avoir été poussés à l'extrême, avec plein de choses pas croyables comme les groupes de substitution et du pseudo héritage machin truc. Alors que pour 90% des échanges de fichiers, tout ce qu'on aurait voulu c'est les minOccurs et maxOccurs avec le type de donnée.round tripping : la conversion de la représentation interne des données dans un logiciel (comme un objet à l’intérieur d’une application Java, des structures dans une solution C, des lignes d’une table Oracle, etc.) au format XML et vice-versa, devrait produire les mêmes données. En d’autres termes : data == DecodeFromXML(EncodeToXML(data)).
Pour les types simples, cela peut êtreCode : <product id="12">
Code : 1
2
3<product> <id>12<id> </product>
Code : 1
2
3
4<product> <category>Computer</category> <category>Hardware</category> </product>
Code : 1
2
3
4
5
6
7
8<product> <categories> <category>Computer</category> <category>Hardware</category> </categories> </product> </product>
Plus subjectivement
XML permet beaucoup de chose, peut être trop,
par exemple ceci :
<hello>
bon<hi>salut</hi>jour
</hello>
cela rend les API de lecture séquentielle style SAX merdiques parce que franchement tout et n'importe quoi peut arriver n'importe quand.
Je pense que le XML pourrait être simplifié, ou une déclinaison de ce format rétro-compatible pourrait exister.
Les contraintes de cette déclinaison pourraient être les suivantes :- Pas d'attributs
- Obligation d'élément de groupe pour les collection
- premier élément optionnel serait <schema> avec une description des types et des contraintes d'apparition sous forme [x,y] des éléments
- deuxième élément serait <data> avec les données
Les avantages seraient les suivants :- Les API de lecture et d'écriture seraient simples comme bonjour. Un noeud, une valeur ou une collection.
- La validation serait 100 fois moins compliquée à décrire et à implémenter de façon automatique à la lecture que dans le cas d'un schéma
- La porte serait ouverte à la génération automatique de classes pour la lecture
En gros ce serait une façon simple de répondre à un problème très courant, très commun qui rend XML pénible là où ce n'est vraiment pas nécessaire.
On aurait des arbres simples, elements-only, très lisibles et validables sans sortir le bazooka.
Parfois je me demande même s'il ne faudrait pas écrire une spec, un exemple d'API puis le proposer.le 28/08/2012 à 9:36 -
kolodzModérateurQuand je survole le document en question et que je compare avec la réalité. Il y a trois choses qui me viennent en tête :
- Un XML qui as une DTD à jours, c'est déjà beaucoup demander.
- Un service qui vérifie qu'on lui donne des XML valide par rapport à sa DTD, c'est encore plus rare.
- Croire que le type, qui décide comment est structuré un XML, connait la théorie des langages, relève du fantasme.
Le problème ne vient pas du langage, mais de son utilisation.
Pour ce qui est du fond, je pense que je lirai cette publication plus tard.
Quelle est l’essence du XML pour vous ?
Lisible par un humain.
Souple.
Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?
Êtes-vous d’accord avec cette conclusion ?
data == DecodeFromXML(EncodeToXML(data))
Cordialement,
Patrick Kolodziejczy.
* : Quand ce n'est pas le cas, un humain peut lire les données et retrouver les données d'origine.le 27/08/2012 à 22:57 -
dufoliMembre à l'essaiCertes le xml est loin d'être parfait et est de plus très verbeux.
Je ne vois pas cela comme un langage mais comme un "format" permettant de représenter des données hiérarchisés.
Je ne vois pas beaucoup d'alternative a ce niveau là.
Pour la configuration avant on avait les fichiers ini et c'était 100 fois plus limité.
Pour la transmission de donnée hiérarchisés, le xml est un format bien plus structuré et lisible que les fichiers plats (texte longueur fixe ou avec séparateur) qui nécessitait un champ type pour séparer entête et ligne.
Bref, faut pas oublié d'où on vient...
Pour finir le JSON est la seul alternative que je connaisse et qui est utilisé à ma connaissance.
Beaucoup d'API REST proposent d'ailleurs le choix entre XML ou JSON.
XML est plus riche que JSON mais bien plus verbeux... Donc ça reste un choix en fonction de ce que l'on a a faire....le 27/08/2012 à 22:45 -
GrandFatherExpert éminentXML, c'est certes un langage de balise d'apparence presque trivial, mais c'est surtout une nébuleuse d'outils, d'API, de frameworks, de langages développés spécifiquement pour lui. Les possibilités sont phénoménales, toute la difficulté revient à en faire l'usage le plus optimal possible ; mais la tentation du « marteau en or », l'outil prétendument universel qu'on met à toutes les sauces - jusqu'à l'indigestion - n'existe pas que pour XML, mais pour tous les outils de développement à fort potentiel. Enfin, ce débat est un peu dépassé... Depuis 13 ans que la spécification existe, on a depuis fait un peu le tour de ce qui était intéressant ou non de traiter avec XML.
Ainsi, XML n'apporte pas vraiment grand chose dans le domaine des fichiers de configuration, alors qu'il est devenu un standard pour les transferts de données entre systèmes (où il a fait ses preuves). Il y a d'autres domaines d'application où XML est incontournable, et qui n'ont pas encore été abordés dans ce fil, ce sont ceux de la bureautique et de la gestion documentaire. L'accession de ODF et OpenXML au rang de normes a vraiment changé la donne.le 28/08/2012 à 14:42 -
MiaowZedongMembre extrêmement actifJe m'interroge sur la pertinence de ce critère pour un format. Il me semble que cela dépend du logiciel qui fait la conversion....s'il n'utilise pas le même découpage dans les deux sens, ce n'est pas la faute au format.
Sinon, je ne pense pas que le XML soit spécialement mauvais, cela dit, il me semble qu'il est utilisé dans de nombreux cas où il ne devrait pas l'être. S'il est utilisé dans des cas où il est inadapté, c'est normal qu'il remplisse mal une tache qui n'est pas la sienne. L'exemple du dictionaire donné plus haut est pertinent, le XML est bien adapté pour formatter un texte, pas pour faire des recherches sur des paires mot-clé:définition.le 28/08/2012 à 17:30 -
el_slapperExpert éminent séniorIl y a plein de manières de représenter les données, d'un format purement utilitaire(le fichier plat à positions fixes), à un format totalement descriptif(ceux qui ont moddé les jeux paradox, genre Europa Universalis, sauront de quoi je parle).
Un format totalement utilitaire est hyper-facile à coder, et très complexe à manipuler à la main(sauf si on a un éditeur dédié). Un format totalement descriptif est le mieux possible pour la modification manuelle, mais est fatalement casse-tête à coder(on est à la limite d'un compilateur).
XML, c'est entre les deux : ça essaye d'être facilement manipulable informatiquement ET à la main. Fatalement, il y a des surprises. C'est lié à la nature même du XML. Ce qui est une force d'un coté est une faiblesse de l'autre. Ca n'est pas un mauvais système, mais il faut en accepter les limites : il est moyen partout.le 28/08/2012 à 10:24 -
el_slapperExpert éminent séniorJe n'y vois qu'une différence de style. Et surtout de manière de travailler. Si le XML est là avant tout pour être attaqué à la main, alors oui, le premier code permet d'économise des frappes de touches. Par contre, si on parse, la deuxième solution évite certains casse-têtes.le 29/08/2012 à 14:39
-
jfchretienMembre du ClubBonjour à tous.
Je pense que tu n'as pas assez poussé ton analyse. On va partir du postulat que les données sont des objets (au sens propre, pas au sens informatique). Chaque objet peut-être décrit de manière syntaxique et/ou sémantique. Je m'explique.
Un objet à des caractéristiques atomiques (composantes syntaxiques) et ensemblistes (composantes sémantiques).
Le sens d'une composante syntaxique est contenu dans le couple définition + contenu (nom=marie, prénom=pierre, taille=160, poids=80) et l'objet auquel elle se rattache. L'ordre des caractéristiques n'a alors pas ou peu d'importance.
Une composante sémantique contient (généralement) sa propre définition CHAPITRE est composé de PARAGRAPHE est composé de PHRASE est composé de MOT. Par contre, si la définition n'est pas forcément nécéssaire, les ensembles n'ont de sens que s'ils sont ordonnés.
Dans tous les cas, XML est suffisament ouvert pour que ses balises permettent de définir des composantes qu'elles soient syntaxiques ou sémantiques.
Oui tout à fait. D'ailleurs à ton avis, un tableau est une composante syntaxique ou sémantique ? Comme c'est une composante sémantique, c'est sa destination qui va en partie définir la façon de le coder.
Pour ce qui est de la question attribut vs. balise, la vraie question à se poser est : est-ce une composante ou une information sur la composante ?
Par exemple un individu pèse 80 kg : On peut l'écrire en XMLCode : <INDIVIDU><POIDS><VALEUR>80</VALEUR><UNITE>kg</UNITE></POIDS></INDIVIDU>
Code : <INDIVIDU><POIDS unite="kg">80</POIDS></INDIVIDU>
D'ailleurs en parlant de destination...
Pour ce qui est du choix TEXTE / CSV / JSON / YAML / XML, j'utilise le raisonnement suivant :
Fichier de conf. écrit et lu par l'application => Texte / CSV (à charge de l'application de gérer le typage et les erreurs sur les données, en écriture et en lecture)
Fichiers d'initialisations écrits par l'utilisateur et lus par l'application pour générer db, templates, docs, ... => JSON / YAML. (à charge de l'application de gérer le typage et les erreurs de données lors de la lecture)
Sérialisation et échange d'objets "simples" intra ou inter-applications => JSON / YAML (à charge des applications de gérer le typage et les erreurs sur les données)
Sérialisation et échange d'objets "complexes" intra ou inter-applications => XML (les développeurs ont accès aux spécifications du XML et les intègrent dans les applications)
Transfert de composantes syntaxiques/sémantiques (données) => XML + XSD + XSLT (les applications ne décident pas des spécifications et/ou de la transformation des données)
Après tout va dépendre des attendus, sachant que vitesse ne rime pas avec robustesse. Si je veux un traitement rapide, je prendrai TEXTE / CSV, tout en sachant que si l'application est mal développée, les risques d'erreur sont assez grands. Si je veux de la robustesse, alors XML + XSD + XSLT. Sachant que l'impact sur la taille des données(occupation réseau, mémoire et disque) et les temps de traitement sera assez fort.
Deux remarques sur le contenu de l'article :
Justement non ! Et c'est là toute la puissance d'XML. D'ailleurs l’ambiguïté se trouve à quel niveau ? Soit au niveau de celui qui a implémenté le XML et qui n'a pas suffisamment bien pensé et spécifié la structure, soit au niveau de celui qui va traiter le XML et qui n'a pas tout les éléments pour comprendre ce qu'il a et comment il doit le traiter.
Pour ce qui est du round tripping, c'est pareil, aux développeurs de produire une structure XML et des procédures d'import/export adaptées...
Encore une fois XML/XSD/XSL définit de la syntaxe et de la sémantique. Rien de plus.
Pour finir et pour répondre à l'article :
Êtes-vous d’accord avec cette conclusion ?
Non. En effet, la phrase (un peu tape-à-l'oeil) "le problème qu’il résout n’est pas difficile et il ne le résout pas bien" pourrait aussi bien s'appliquer à Java, Perl, LaTeX et tout autre langage ou format... Tout va dépendre du problème posé et du contexte dans lequel s'inscrit ce problème.
Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?
Très puissant si on l'utilise correctement pour résoudre les bons problèmes. Très lourd et parfaitement inéfficace dans de nombreux cas.
Il lui manque sûrement plein de choses, mais à trop vouloir en faire un langage universel et respectant pléthore de contraintes, on risque d'en faire une usine à gaz inexploitable et impossible à mettre en oeuvre.
Quelle est l’essence du XML pour vous ?
Permettre le stockage, l'échange et le traitement/transformation de composantes syntaxiques et/ou sémantiques dans des contextes hétérogènes et/ou complexes.le 30/08/2012 à 18:03 -
_skipExpert éminentBon faut quand même pas tirer loin le bébé avec l'eau du bain
- Lourd à lire par l'homme, non, regarde un fichier de config de filezilla par exemple, c'est pas du tout dur à comprendre.
- Long à modifier, je vois pas en quoi changer une valeur en XML est plus dur que modifier une entrée dans un fichier texte.
- Lourd en place, sachant que souvent, qu'il fasse 1 octet ou 4096 il occupera peut être bien la même place. Puis est-ce vraiment l'argument de poids dans une machine ou 1To de disque est devenu la norme?
- Lourd à parser... Ca c'est vrai, mais est-ce significatif sachant qu'un fichier de configuration est généralement suffisamment petit et lu et écrit d'une traite?
Malheureusement, cette condition est souvent bien trop restrictive de nos jours où on parle que d'internationalisation. Là j'opterai plus pour une solution style protocol buffer.
Pour ceux qui vont m'objecter que dans un fichier de configuration plat, on ne peux pas avoir de structure en arbre... J'ai une chose à dire.
Un système de fichier, ça ne comporte pas que des fichiers, mais aussi des dossiers.
Hors, le système dossier/fichier, est une structure arborescente. S'il est vraiment nécessaire d'avoir une structure en arbre pour une configuration, alors utilisez le système de fichier.
J'aurai mieux compris si tu avais cité un truc comme le format utilisé par Xorg dans ses xorg.conf.le 28/08/2012 à 11:12 -
polymorphismeMembre émériteBonjour,- Bien comme format d'échange, il est totalement nul pour tout ce qui est ressource un peu statique et qui doit être modifiée par des humains. XML est mal utilisé pour ça, mais JSON est juste risible.
Préférer un format CSV au format XML ou l'inverse pour des raisons personnelles de goût me laisse sans voixIl est clair que CSV n'a pas les mêmes spécificités que XML. Chacun de ces formats ne peut juste être utiliser pour leurs spécificités propres.
Et il est clair qu'il existe des domaines tel que la gestion documentaire où le XML est roi.
Comment créer un dictionnaire, un thésaurus, un livre sans XML ? Je souhaite bon courage à ceux qui voudraient s'en passer.
Enfin, la bestiole data == DecodeFromXML(EncodeToXML(data))
me fait penser à Infoset, qui est le standard traitant de l'information extraite d'un fichier XML et il me semble que cela fonctionne plutôt bien.
Je crois que XML à apporter de nombreuses améliorations dans divers domaines
et que cela va continuer.le 28/08/2012 à 16:28