Discussion :

[rt15]

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.

Réponse naïve, certainement, mais j'ai envie de dire : "Ah bon ???".

Ok, pour qqch office, word, tout ça, maintenant, c'est le xml qui est privilégié... Bonne idée ou non je sais pas. De toute façon, ce xml, on le voit pas.
Reste que pas mal de documents restent hors xml, tel que les pdfs.
Et dans les entreprises, pas mal de "documents" sont encore des fichiers plats (Question de perfs, de place, logiciels existant, passif COBOL...).

Pour l'exemple du dictionnaire, xml est très adapté... Si on veut un logiciel lent !
Je vois d'ici un énorme fichier xml parsé à chaque démarrage du logiciel. Trop génial. Nan, quand il y a du volume, autant passer par des fichiers indexés. Ça boost carrément mieux. Genre déjà un fichier avec un mot tout les 40 caractères, trié... Tu le charge tel quel en mémoire et tu fais de la recherche dichotomique dessus... Bin là mamie elle attend plus pour faire son scrabble.

Pour le thésaurus, je me prononce pas. Peut être un bon exemple.

Pour le livre... Connais pas. Des exemples ??? Je sais que pas mal de documents scientifiques et de livres scientifiques aussi sont fait en LaTeX et que ça poutre pas mal. Ça fait détester word notamment. Eh bin c'est pas du xml.

[MiaowZedong]

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

[GrandFather]

Reste que pas mal de documents restent hors xml, tel que les pdfs.

Oui, et c'est une plaie quand il faut les intégrer dans une gestion documentaire.

Un fichier PDF, c'est pratiquement du Postcript, c'est à dire un format descriptif des primitives graphiques nécessaires pour imprimer le document (blocs de texte, lignes, couleurs, etc.). La structure logique du document textuel, i.e. sa décomposition en titres, paragraphes, sections, etc. est totalement perdue. Il n'y a guère que les metadonnées (auteur, date de création, etc.) qui soient libellées en interne comme telles (et en XML le plus souvent ) et récupérables relativement facilement.

A contrario, ODF (et OpenXML) décrivent la structure logique du document. Ca ouvre des possibilités très puissantes de gestion de son contenu, et d'exploration sémantique.

Pour le livre... Connais pas. Des exemples ??? Je sais que pas mal de documents scientifiques et de livres scientifiques aussi sont fait en LaTeX et que ça poutre pas mal. Ça fait détester word notamment. Eh bin c'est pas du xml.

Docbook pour la documentation technique, notamment informatique, est un standard très utilisé. Latex, c'est le même syndrome que PDF: excellent pour obtenir une impression impeccable, épouvantable quand il s'agit de récupérer des informations sur la structure logique du document.

[Bktero]

Latex, c'est le même syndrome que PDF: excellent pour obtenir une impression impeccable, épouvantable quand il s'agit de récupérer des informations sur la structure logique du document.

Et c'est d'ailleurs le but (unique ?) de LaTeX

D'ailleurs, je ne vois pas trop ce que LaTeX vient faire dans la discussion, il n'y a rien de commun entre les deux "langages". Comme l'a dit MiaowZedong et plusieurs personnes avant lui, chaque technologie (langage, format, logiciel) sert à remplir certaines tâches et si on souhaite l'utiliser pour autre chose, il ne faut pas s'étonner que ça ne marche pas aussi bien. Il ne viendrait à personne l'idée de se dire "tiens, j'ai une vis plate, mais un tournevis cruciforme c'est génial alors je vais m'en servir".

[Freem]

Et là encore tu vas me dire que tu peux t'en sortir avec des sections, et c'est vrai.

La vraie question, c'est pas de savoir si on peut, mais de savoir si c'est plus adapté.
Moi, je pense que le fichier INI, par exemple, l'est très souvent, plus adapté, pour de la conf (ou un autre format texte du même genre, bien sûr).
Parce que, effectivement, XML permet de le faire, je ne le nie pas une seule seconde. Mais, pour moi, il le fait mal.

Cependant, le problème de ces notations c'est lorsque tu as des collections et des sous-collections de propriété, ça devient fastidieux et tu ressens le besoin d'une structure hiérarchisée.

A l'époque ou j'ai conçu mon avis sur XML, je suis tombé sur YAML (qui a été cité un peu plus haut mais que tout le monde semble avoir ignoré...) et je l'avais oublié.
Je ne sais pas ce qu'il vaut pour la conf, mais vu qu'il a une structure proche de celle d'une classe, si je me souviens bien, du coup je pense que dans un certain nombre de cas, il serait nettement plus adapté.

Je pensais à ceci
http://code.google.com/p/protobuf/

Je ne connaissais pas, merci beaucoup.
Mais du coup tu casses le seul domaine où je pensais XML intéressant

Dans le cas de ton application qui persiste sa config, il est probable que tu choisisses de détruire totalement une arborescence [...]
Dans le cas d'un fichier unique, il y a quelque chose de très simple, écrire dans un fichier temporaire puis ensuite renommer le fichier vers sa destination finale (quasiment 100% safe).

C'est vrai. D'un autre côté, le système temporaire marche aussi avec une arborescence, il suffit de déplacer les dossiers racines: l'un dans un coin pour garder une sauvegarde, l'autre à sa destination. Reste le problème des droits, c'est sûr, mais seul un utilisateur et un admin devraient avoir le droit de travailler sur la conf de cet utilisateur. Et l'admin ne devrait pas être utilisé pour ça, ou savoir qu'il doit refiler les droits à l'utilisateur.

Et l'assertion que l'on refait tout à 0 en cas de souci n'est pas nécessairement vraie, notamment dans le cas de l'usage de plug-ins. Mon avis dans ce cas particulier de plus en plus à la mode (pas sans raisons d'ailleurs) c'est qu'il vaut mieux des fichiers séparés.
Ca permet de supprimer un plug de l'appli simplement ou de faire évoluer plus aisément la conf par défaut sans devoir chercher dans un immense fichier XML la zone réservée à ce plug-in.

Je disais juste que t'y allait un peu fort en disant que c'était dans tous les cas une mauvaise idée pour enregistrer de la configuration (ou par extension, des états).

C'est juste que je réagissais à quelqu'un qui disait que les fichiers INI sont 100 fois moins puissants.
J'en ai juste marre des fanatiques de l'XML alors que ce format n'a rien de magique. Il n'est pas mauvais en sois, il est juste mal utilisé dans 80% des cas (je suis gentil, je meure d'envie de dire 95% de ceux que j'ai vus), et les gens le prennent pour la panacée!
Hors, avant XML, on se démerdait très bien.
XML pour l'indexation? Ca ne remplace pas, et ne remplacera jamais, une base de données. Mieux vaux access ou sqlite3 si c'est à la fois trop petit pour une vraie BDD. Au pire, d'autres BDD permettent d'avoir des bases exportables, et SQL à le mérite d'être connu.
XML pour la conf? On en a parlé.
XML pour la communication réseau? J'ai pas encore lu ton doc...

Il y a aussi les cas de l'échange de données, lorsque lesdites données passent très mal en CSV (genre il faudrait extraire une fois en dry-run pour voir combien de colonne il faut avant d'être en mesure de générer le fichier).

CSV me semble utile pour faire migrer des bases, rien de plus. Après, je suis pas expert du CSV ni de la BDD.

Je parlais surtout par rapport à ton idée d'utiliser l'arborescence du système de fichier, pour les raisons citées plus haut et la difficulté à recouvrer d'un état d'échec au beau milieu de l'écriture.

Certains les gèrent bien au travers des exceptions (autre débat ça, les exception, mais moi j'aime bien pour les erreurs qui ne dépendent pas du programme). Après, ça fait peut-être un peu plus de code, oui, mais avec une conception correcte, je n'en suis pas si sûr. Au final, le code avec XML se trouve dans une librairie et je doute qu'il ne fasse que 2-3 Kio de texte.
Pour la difficulté de retomber sur ses pattes si une écriture à foiré... Je vois pas. Suffit de lancer une exception, après le programme, il a le choix de refaire le fichier, de tout dégommer, d'avertir l'utilisateur et/ou de se suicider. Classique.
En XML, ça se passe comment si tu as une erreur d'IO? Que ce soit réseau ou disque dur... la réponse, c'est que ça dépend de la lib. Normal d'ailleurs.

J'ai aussi déjà démarré sur un écran noir après avoir joué avec ce fichier. Ce n'est pas le format qui fait que ce soit de la daube à éditer pour le coup.

Certes. A la décharge de Xorg, faut dire qu'il s'agit d'un serveur X, protocole qui accuse son âge: il est plus vieux que directX, je pense (1984)

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

Moins verbeux qu'XML, sinon, même combat on dirait (moins verbeux signifie aussi mois long à parser: moins de caractères à traiter).
Pas DTD pour vérifier automatiquement, mais a part les formats du W3C, je n'ai jamais vu de DTD. Les formats, car je pense aussi que XML n'est pas un format, en soit, mais un langage qui sert à créer des formats. Et pour avoir un format correct, il faut une DTD. Manque de bol, les utilisateurs d'XML l'oublient souvent, j'ai l'impression.
D'ailleurs, c'est marrant de dire "JSON est une abbréviation de XML" et ensuite "pour un échange de données et JSON cela s'arrête là".
Contradictoire, non?

Je crois que XML à apporter de nombreuses améliorations dans divers domaines
et que cela va continuer.

Je veux bien des exemples alors.
Il est tellement performant et sur-puissant, ce format, que certains dev regrettent d'avoir utilisé XML pour leurs projets, je pense notamment à Code::Blocks ou les gens pensent finalement qu'ils auraient dû utiliser autre chose pour les fichiers de projet et de workspace (suffit de fouiner dans le forum tu devrais avoir des références dans les archives). Après, je ne connais pas les raisons exactes, il me semble juste l'avoir compris au travers de certains commentaires.

Il ne viendrait à personne l'idée de se dire "tiens, j'ai une vis plate, mais un tournevis cruciforme c'est génial alors je vais m'en servir".

Par contre il m'arrive d'utiliser un tournevis plat pour une vis cruciforme, et un couteau pour une vis plate... mais bon, c'est quand j'ai la flemme de déplacer mes fesses

Pour le reste... XML vs LaTeX&PDF:
Mettre les métadonnées dans le fichier qui le contiens, je ne parviens pas à trouver cela logique. Tu fais comment dans ce cas pour indexer un document uniquement physique? Tu le réécris en XML pour pouvoir y ajouter tes méta?
J'ai plus dans l'esprit une base de données qui contienne les titre des bouquins, leurs auteurs & co.

L'exemple du format PDF est intéressant sur ce point: il montre que XML n'est peut-être pas si intéressant que ça pour l'ensemble d'un document, surtout si celui-ci ne doit pas être modifiable. Comme tu l'as souligné, dans un PDF, seules quelques méta-données (et pas toutes) utilisent XML.
Pourquoi? Sûrement parce que XML n'est pas fait pour présenter un document... D'ailleurs, CSS, c'est pas un peu son but de s'occuper de la présentation d'un fichier XML? Si c'est pour me dire que CSS est en couple avec HTML... Il me semble que c'est avec XHTML qu'il est, et que ce dernier est un fichier XML avec une DTD qui le fait ressembler à HTML.
Mais, je peux me planter, je ne connais pas trop le web.

Pour les livres, LaTeX est, pour moi, plus adapté (et peut au pire générer des documents XML). D'ailleurs, puisqu'il faut parser le XML pour faire le rendu, pourquoi ne pourrait-on pas parser directement LaTeX pour faire le rendu, en indexant les données qui nous intéressent? C'est ce que le compilateur LaTeX fait quand il crée le sommaire, notamment, donc, c'est possible.
Et LaTeX est de loin plus aisé à lire.
(Ce que LaTeX viens faire dans la discussion, c'est le fait que pour certains, il s'agit d'un meilleur langage que XML dans le cas de l'édition de ressources documentaires. Mais en effet, il ne sert pas à faire communiquer 2 programmes, ce n'est pas son rôle, tout comme le rôle de XML n'est pas d'éditer des documents. Les choses extensibles pour faire le café ne font pas de bon café.)

Pour les dictionnaires, un PDF suffit, puisque si tu cherches un mot, tu sais quel mot tu cherches, donc un CTRL+F suffit (mot entier+début de ligne devrait éviter les résultats parasites si le dictionnaire en question est bien fait, ou alors en incluant le séparateur mot/définition).
Et même dans ce cas, +1 d'ailleurs pour le fichier indexé.
Si ça continue, on nous collera des systèmes de fichiers avec les "métadonnées" en XML...

Pour le thésaurus, je ne me prononce pas, parce que je ne sais pas m'en servir.

[JakoJako]

Ce qu'il me semble manquer, c'est quelque chose pour décrire un peu de typographie dans du texte sans être obligé de mettre de la 'vraie' structure.

Par exemple, si on veut écrire "Les émissions de CO2 ont augmenté" correctement, on va mettre quelque chose comme

<Text>Les émissions de CO<inf>2</inf> ont augmenté</Text>

Du coup on crée de la 'fausse' structure (<inf>2</inf>) qui surcharge inutilement la vraie structure...

On peut bien sur ruser avec de PI mais ce n'est pas très joli non plus

<Text>Les émissions de CO<?XXX sup>2<?XXX finsup> ont augmenté</Text>

A part ça, je trouve le XML assez bien adapté dès qu'on a des structures un peu compliquées et surtout hiérarchiques et avec des occurrences. La validation en utilisant un schéma ou une DTD permet d'éviter des erreurs triviales de structure - même si ça peut sembler un peu lourd à mettre en place.

[nidget]

Le XML, c'est comme la violence: si vous n'êtes pas satisfaits du résultat, c'est plus que probablement parce que vous n'en avez pas utilisé suffisamment. Remettez-en une couche immédiatement!

[enneite2]

Je me suis toujours demandé pourquoi utilise-t-on des attributs au lieu de rajouter des sous-balises ...
Pour moi, les attributs, c'est vraiment une plaie

[tralloc]

A l'inverse, moi j'aime bien utiliser les attributs, comme ça le texte est bien encadré par des guillemets. J'utilise en général les sous balises pour indiquer une multiplicité. Chacun sa façon de faire !

[bugsan]

Les reproches fait à XML sont entièrement imputables aux développeurs. Il y aurait tellement de chose à dire...

1) La méconnaissance du format lui même. La méconnaissance du charset/encoding des caractères, pour des juniors comme par des séniors.
2) La total ignorance des outils de manipulation XML. 9 développeurs sur 10 viennent me montrer leur code qui concatène des chaines "<balise>"+valeur+"</balise>". Ca donne envie de meurtre. Mais en même temps je crois qu'aucune école en France n'explique comment (en java) utiliser l'API SAX, pour parser et pour générer du XML. Encore moins stax.
3) L'ignorance des devs en matière de théorie des langages. XML est souvent utilisé comme structure porteuse pour un pseudo langage (DSL). Pourquoi un format XML et pas un autre ? Pourquoi pas un format "maison" ? Une raison communément admise (e.g. Martin Fowler) est que des outils existent déjà, mais mon point 2) invalide cet avantage ...
4) L'utilisation abusive du terme "fichier de config" pour tout et n'importe quoi qui peut être édité à la main sans nécessiter de compilation. Une partie de ces fichiers pourraient être remplacé par un bête fichier "clé=>valeur", genre fichier properties. Les autres ne sont pas des fichiers de config, mais des mini-langage à mettre au même niveau que C ou Java. Ou alors on peut s'autoriser à dire "j'ai édité le fichier de config de la classe machin" en parlant d'un .java
Et il y a aussi des documents avec de belles structures hiérarchiques et les appeler "fichier de config" parce qu'un malin peut aller l'éditer c'est juste . Ces fichiers sont utilisés comme des bases de données documents, dont on pourrait se passer d'une édition manuelle avec une belle interface.


EDIT: a propos de la différence attribut/balise. J'utilise toujours des attributs, qui se rapportent à un élement, et ces élements sont des balises. Il suffit de regarder tous les autres langages balisés pour voir que les attributs sont bien plus pratiques que les balises : HTML, xsl/fo, les fichiers spring ...
On écrit bien <div class=""/> et non <div><class></class></div>... Cet exemple montre à quel point des préjugés sur XML durent depuis 10 ans, et sont tenaces.

[rt15]

Je me suis toujours demandé pourquoi utilise-t-on des attributs au lieu de rajouter des sous-balises ...
Pour moi, les attributs, c'est vraiment une plaie

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 - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[bugsan]

rt15 a été plus rapide que moi ^^

[el_slapper]

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 - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[tralloc]

Par contre, si on parse, la deuxième solution évite certains casse-têtes.

Si tu utilises un parser correct, je ne vois pas le casse tête

[tralloc]

@el_slapper

Et le serment de non-allégiance :

allégeance

[BenoitM]

Xml est peut-être lourd quand tu dois transféré des fichiers mais lourd pour un fichier de config?
Quand on a des disques de plusieurs Giga, c'est sur que c'est les 10ko en plus qui sont important...

CSV facile à lire/modifier? bon quand on l'ouvre avec excel peut-être mais quand on doit compter le Xième ";" en plus ca ne marche que pour des fichiers plat a structure fixe sinon ca devient le bordel
Bon on peut faire plusieurs fichiers mais bon pas toujours pratiques

[bugsan]

Si tu utilises un parser correct, je ne vois pas le casse tête

Réinvention de la roue carrée, toussa

[GrandFather]

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.

Il y a quand même quelques caractéristiques spécifiques des éléments et des attributs qui ne les rendent pas totalement interchangeables. Par exemple:

1. La cardinalité : un attribut est unique au sein d'un élément, un élément peut avoir plusieurs occurrences dans le même élément parent
2. L'ordre : La spécification du W3C n'oblige pas les parseurs à restituer les attributs dans le même ordre que celui apparent dans le document sérialisé ; a contrario, l'ordre des éléments restitué par le parseur doit être le même
3. La normalisation : les blocs CDATA ne sont pas autorisés dans les attributs, et la gestion des espaces n'y est pas la même que dans les éléments (ils sont notamment interdits en cas d'énumération des valeurs autorisées par une DTD)
4. Les espaces de noms : il n'existe pas d'espace de noms par défaut par les attributs

Ces différences, plus ou moins subtiles, font que par convention (plus ou moins respectée...) les attributs contiennent des metadonnées véhiculant des informations sur l'élément qui les arbore, tandis que les éléments sont des « objets » à part entière composant leur élément parent.

Mettre les métadonnées dans le fichier qui le contiens, je ne parviens pas à trouver cela logique. Tu fais comment dans ce cas pour indexer un document uniquement physique? Tu le réécris en XML pour pouvoir y ajouter tes méta?

Tu prends le problème à l'envers. Ce que tu appelles « fichier physique » est un fichier destiné au rendu final (écran, papier) d'un document. Il n'a pas vocation à alimenter une gestion documentaire (mais peut être produit par elle), il suffit de consulter la spécification PDF par exemple pour s'en persuader (à l'exception notable de l'intégration des metadonnées). A partir du moment où le document a été sérialisé dans un fichier pour être « lu » (ou échangé), il est logique que ses metadonnées y soient intégrées et voyagent avec lui.

D'ailleurs, une gestion documentaire, ce n'est pas seulement indexer des documents selon des mots clés ou leur auteur ; c'est aussi permettre des opérations puissantes d'édition des document eux-mêmes, établir des modèles, faire respecter une charte graphique, etc. Toutes ces choses sont extrêmement difficiles, sinon impossibles, à faire avec des fichiers dont le format n'est pas prévu pour cela à l'origine. C'est le cas de PDF et, dans une moindre mesure, de Latex, qui sont des formats de présentation et non de modélisation des documents. A contrario, ODF et OpenXML ont été conçus dans cette optique.

[astroflo]

J’ai utilisé le XML dans le milieu industriel...
Effectivement il y a des règles de codages qui ne sont pas très rigoureuses.
J'utilisais le XML comme fichier de config

Pour générer automatiquement un fichier d'instruction pour un simulateur.

Cependant si on génère un fichier xsd de manière claire. Cela permet de tester le fichier xml générer par l'utilisateur suivant un patern donnée, ou d'une manière plus avancé générer automatiquement le fichier xml avec une IHM, et avant toute opération vérifier la validité du fichier.

Je suis d'accord qu'il faut avoir en tête les règles de code usité pour être rigoureux.
Cependant avec un fichier xsd bien fait, le fichier xml créer sera validé automatiquement par le xsd avant l'utilisation de cette moulinette.

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

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.

Des formats conçus pour encoder des structures de données, il y en a quelques-uns. JSON, cité plus haut, mais aussi par exemple YAML. Mais c'est vrai que sous leur forme actuelle ces formats ont un défaut : ils ne sont pas typés et ne proposent pas de formalisme pour décrire une structure, à l'instar des DTD et schémas XML. Mais je crois savoir que pour JSON, une spécification est en cours.