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

Expert éminent

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 :

Sélectionner tout

<product id="12">

Ou alors

Code :

Sélectionner tout

1
2
3
<product>
<id>12<id>
</product>

Pour les collections :

Code :

Sélectionner tout

1
2
3
4
<product>
<category>Computer</category>
<category>Hardware</category>
</product>

Ou alors

Code :

Sélectionner tout

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.

10

0

kolodz

Modérateur

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.

9

0

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

8

1

GrandFather

Expert éminent

Le 28/08/2012 à 14:42

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

6

0

MiaowZedong

Membre extrêmement actif

Le 28/08/2012 à 17:30

Envoyé par Hinault Romaric

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

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

5

0

el_slapper

Expert éminent 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.

4

0

el_slapper

Expert éminent sénior

Le 29/08/2012 à 14:39

Envoyé par rt15

Peut être parce qu'ils se sont aperçut que ça pouvait être lourd d'utiliser des sous balises. Exemple pour du xhtml ->

Code :

Sélectionner tout

<button name="action" value="send" type="submit">Send</button>

Code :

Sélectionner tout

1
2
3
4
5
6
<button>
  <name>action</name>
  <value>send</value>
  <type>submit</type>
  <caption>Send</caption>
</button>

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

4

0

jfchretien

Membre du Club

Le 30/08/2012 à 18:03

Bonjour à tous.

Envoyé par esperanto

Je crois surtout que les gens ont oublié un point fondamental: XML a été conçu à l'origine pour encoder des documents textuels, or aujourd'hui beaucoup veulent l'utiliser pour encoder des structures de données, ce pourquoi il n'a pas été conçu. Pas étonnant donc qu'il ne réponde pas à 100% à la problématique.

Un texte, c'est quelque chose de fondamentalement linéaire : prenez un document Docbook, ôtez toutes les balises mais maintenez l'ordre, vous verrez que l'ensemble reste compréhensible. Avec des structures de données c'est le contraire: quand vous spécifiez par exemple un objet Personne, peu importe que le nom vienne avant ou après le prénom, par contre si vous gardez le contenu sans les balises, ça devient ambigu.

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.

Envoyé par esperanto

Résultat?
XML est utilisé de plein de façons différentes. Dites-moi un peu : comment encodez-vous un tableau en XML? Je suis presque sûr que si plusieurs personnes répondent à mon message vous aurez autant de façons totalement différentes, sans qu'on puisse dire avec certitude qu'une est meilleure que l'autre dans tous les cas.

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 XML

Code :

Sélectionner tout

<INDIVIDU><POIDS><VALEUR>80</VALEUR><UNITE>kg</UNITE></POIDS></INDIVIDU>

ou

Code :

Sélectionner tout

<INDIVIDU><POIDS unite="kg">80</POIDS></INDIVIDU>

Mais dans le cadre d'un individu, l'information "kg" est-elle une composante qui a un sens ? Pas forcément, car elle est un qualificatif de la composante "poids". Il en va de même pour un style de paragraphe, la fonte d'un titre, ... On devrait donc utiliser les balises pour les composantes et les attributs pour les qualificatifs des composantes. Toutefois, je dis bien "on devrait" car celà va dépendre de la destination du fichier XML...

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 :

Envoyé par Hinault Romaric

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

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.

4

0

_skip

Expert éminent

Le 28/08/2012 à 11:12

Bon faut quand même pas tirer loin le bébé avec l'eau du bain

Envoyé par Freem

Franchement, XML pour de la configuration, c'est ridicule, parce que ton fichier de configuration deviens (comparé à du texte brut):
_ lourd à lire par l'homme
_ très ardu/long à modifier par l'homme
_ lourd en place sur le disque dur
_ lourd à parser pour la machine

XML pour de la configuration, ça sert à fabriquer des bloatwares.

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

Envoyé par Freem

XML Règle ce problème, étant donné qu'il s'agit de texte, encodé sur 1 octet. D'ailleurs, il peut même être encodé sur 7 bits, ce qui permet une forme de compression, à condition que l'on accepte d'utiliser l'encodage ASCII au lieu d'UTF8 ou autre.

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.

Lourdeur, lenteur, difficulté à lire, difficulté à modifier, plein de possibles erreurs IO à gérer, pleins d'arbre de répertoire à explorer en depth first, gestion d'erreur et tout ça. Ca a juste tous les problèmes que tu as mentionnés au début de ton post dont certains en x10.

J'aurai mieux compris si tu avais cité un truc comme le format utilisé par Xorg dans ses xorg.conf.

3

0

polymorphisme

Membre émérite

Le 28/08/2012 à 16:28

Bonjour,

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

J'en pense pas moins, JSON est une abréviation de XML qui peut s'avérer pratique effectivement pour un échange de données et JSON cela s'arrête là.

Préférer un format CSV au format XML ou l'inverse pour des raisons personnelles de goût me laisse sans voix

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

3

0

Identifiez-vous

Créer un compte

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

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

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