"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 ?

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux


 Discussion forum

Sur le même sujet
Le , par Hinault Romaric, Responsable Actualités
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 :

  • 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 ?

Ê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 ?


 Poster une réponse

Avatar de thelvin thelvin
Modérateur
le 27/08/2012 19:20
Ils ont raison. Personnellement j'utilise peu XML pour le cas d'utilisation qu'ils présentent. Il n'a pas ces défauts pour moi, et il résout mes problèmes presque aussi bien que possible. Mais je suis un extraterrestre.
Tout le monde utilise XML pour le cas d'utilisation qu'ils présentent, et il a effectivement les défauts montrés, qui gâchent tout.

Le vrai problème de XML c'est qu'il n'a pas de concurrent sérieux, qui copie sa syntaxe pour la lisibilité, qui soit bien intégré, mais qui soit dédié uniquement à ce pour quoi l'industrie s'en sert : des données organisées en séquence et en arbre. Un tel format pourrait auto-décrire les données de la manière présentée, ce qui résoudrait du même coup le round tripping.
Avatar de Xinu2010 Xinu2010
Membre confirmé
le 27/08/2012 19:37
Citation Envoyé par thelvin  Voir le message
Le vrai problème de XML c'est qu'il n'a pas de concurrent sérieux, qui copie sa syntaxe pour la lisibilité, qui soit bien intégré, mais qui soit dédié uniquement à ce pour quoi l'industrie s'en sert : des données organisées en séquence et en arbre. Un tel format pourrait auto-décrire les données de la manière présentée, ce qui résoudrait du même coup le round tripping.

Quid de json ?
Avatar de thelvin thelvin
Modérateur
le 27/08/2012 21:55
Citation Envoyé par Xinu2010  Voir le message
Quid de json ?

Pas sérieux.

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

- C'est moins important, mais il n'est pas lisible au format texte, du moins pas si on mêle tableaux et objets, ou si on va à une profondeur de quatre ou plus. D'ailleurs à cette profondeur, si on mêle objets et tableaux, même un visualiseur de JSON n'arrangera pas beaucoup les choses.
Avatar de dufoli dufoli
Membre à l'essai
le 27/08/2012 22:45
Certes 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....
Avatar de kolodz kolodz
Expert Confirmé
le 27/08/2012 22:57
Quand 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 ?

Format de représentation trans-langage, trans-application neutre par rapport à celle-ci.
Lisible par un humain.
Souple.
Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?

Des utilisateurs sérieux.
Êtes-vous d’accord avec cette conclusion ?

D'un point de vue théorique, je ne sais pas. D'un point de vue pratique, le langage fonctionne et on a la plus part du temps *:
data == DecodeFromXML(EncodeToXML(data))

Donc, j'avoue que la conclusion n'est pas intéressante.

Cordialement,
Patrick Kolodziejczy.

* : Quand ce n'est pas le cas, un humain peut lire les données et retrouver les données d'origine.
Avatar de abriotde abriotde
Membre confirmé
le 28/08/2012 8:47
Quid de json ?
Pas sérieux.

Pour moi le défaut n°1 de XML est sa lourdeur. Je lui préfère le CSV quand ce c'est possible ou le json, le fichier properties et sinon la base de donnée Mysql qui s'exporte très bien (vers une autre du même type).

Pour stocké 1Ko octet de donné on obtient souvent 5Ko, que l'on peut compressé ce qui ne résout que le problème de la taille (On passe à 2Ko) car après le chargement est très très long (Décompression en plus d'un parsing complexe à développer et qui pour simplifier est entièrement stocké en mémoire). Json résout tous ces problème (Il est un peu moins lisible (et encore)) il est deplus dans certains langages (Javascript - PHP et d'autres) possible de faire data==decodeJson(EncodeJson(data)) et d'un point de vue parsing, comme le fichier est moins volumineux il est de facto plus vite lu.

Mais surtout pour envoyer certaines données le csv est ce qu'il y a de plus rapide à chargé. On le charge ligne par ligne, il ne prends donc pas d'espace mémoire, on peut même stocké un gros fichier directement et efficacement en base (MySQL au moins)

Dire que le XML peut tout stocker est une abération tout comme dire qu'il y a un langage pour tout faire. Il faut s'adapter aux besoins.
Avatar de tralloc tralloc
Membre éprouvé
le 28/08/2012 9:29
XML pour moi est un langage très intéressant, je m'en sert pour des importations/exportations de données principalement, ou pour de la config.

Lire qu'on peut utiliser du CSV à la place me fait doucement rire, le CSV est beaucoup moins puissant puisqu'il n'est pas arborescent, autrement dit ce n'est pas comparable. Mais il est vrais que les exportateurs de bases de données par exemple produisent un XML qui pourrait ressembler à du CSV, donc inintéressants, et que pour avoir quelque chose de correct il faut en créer soi même la structure.

Le problème soulevé du format principalement pour des nombres et des caractères spéciaux sur l'encodage/décodage du XML est réel, mais c'est toujours contournable, il suffit de bien prévoir ses programmes et voir quel type de données on va avoir, comment vont-elles être écrites, à partir de là on peut tout faire, ça demande du travail OK.

Pour le "Self describing" : je ne comprend pas, je pense que c'est un langage tellement souple qu'on peut en faire ce qu'on en veut, tant qu'on sait ce qu'on fait, on peut bien si on le souhaite incorporer des langages de description.

Au niveau des DTD je pense qu'on oublie le XMLSchema qui est plus facile à aborder à mon sens, je trouve ça très lourd et je ne l'utilise que pour des langages XML spécifiques (xslt, xsl-fo), je n'en produit pas moi même ça ne sert à rien dans le cas d'une utilisation "pour soi-même".
J'aurais beaucoup plus de reproches à faire au XSLT qu'au XML... mais ce n'est pas le sujet.

En ce qui concerne le JSON je pense que c'est un concurrent intéressant, mais que je connais peu.
Avatar de rambc rambc
Membre Expert
le 28/08/2012 9:30
Citation Envoyé par thelvin  Voir le message
- 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.

Un exemple ?

Citation Envoyé par thelvin  Voir le message
- C'est moins important, mais il n'est pas lisible au format texte, du moins pas si on mêle tableaux et objets, ou si on va à une profondeur de quatre ou plus. D'ailleurs à cette profondeur, si on mêle objets et tableaux, même un visualiseur de JSON n'arrangera pas beaucoup les choses.

Il est bien connu que XML est très facile à lire...
Avatar de _skip _skip
Expert Confirmé Sénior
le 28/08/2012 9:36
Je 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é ;

Je suis d'accord avec eux, c'est un gros problème lorsqu'on travaille avec des flux externes d'autres entreprises. Normalement on se dit qu'on doit pouvoir à partir d'un échantillon pouvoir fabriquer un parser. C'est le cas, sauf qu'au fil des jours on finit toujours par tomber sur le truc qu'on pouvait pas deviner.
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)).

Là aussi, car il y a plein de façons de représenter les données.
Pour les types simples, cela peut être

Code :
<product id="12">
Ou alors

Code :
1
2
3
<product> 
<id>12<id> 
</product>
Pour les collections :
Code :
1
2
3
4
<product> 
<category>Computer</category> 
<category>Hardware</category> 
</product>
Ou alors

Code :
1
2
3
4
5
6
7
8
 
<product> 
 <categories> 
    <category>Computer</category> 
    <category>Hardware</category> 
 </categories> 
</product> 
</product>
En fait c'est plutôt dommage qu'on n'ait pas choisi de se cantonner à une représentation standard.

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.
Avatar de el_slapper el_slapper
Expert Confirmé Sénior
le 28/08/2012 10:24
Il 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.
Offres d'emploi IT
Ingénieur de production
CDI
Paris Incubateurs - Ile de France - PARIS
Parue le 09/04/2014
Stage en contrôle de gestion H/F
Stage
Lagardere Active Presse - Ile de France - Île-de-France
Parue le 28/03/2014
Consultant Chef de projet CRM (H/F)
CDD
Links IT SERVICES - Pays de la Loire - Pays de la Loire
Parue le 08/04/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula