xml pourquoi cette syntaxe ? - Page 1

Je me suis toujours demandé (et j'en profite pour créer un topic parceque je me fais chier) quelles étaient les raisons qui avaient conduit à la syntaxe du XML, et plus précisément celle des balises fermantes.

Un fichier XML valide s'écrit de la façon suivante :

<pwic>
    <plop attr="kikoo">
        <plup>texte</plup>
    </plop>
</pwic>

Pourquoi donc faut-il préciser à nouveau le nom de la balise qu'on ferme, puisque de toutes façons croiser les balises est interdit ? Par exemple j'aurais trouvé une syntaxe comme celle-ci plus logique :

<pwic>
    <plop attr="kikoo">
        <plup>texte</>
    </>
</>

(en plus ça rend la syntaxe des balises auto-fermantes, <balise />, bien plus logique puisque pour le coup il s'agit bien de la concaténation d'une balise ouvrante et d'une balise fermante sans contenu)

De toutes façons quand on ferme une balise, on ne choisit pas laquelle : c'est forcément la dernière qui a été ouverte. Le fait de re-préciser son nom fait double emploi et introduit même un risque d'erreur qui n'existerait pas si un simple </> était suffisant. Par ailleurs, ça augmente sensiblement la taille des fichiers XML (surtout ceux particulièrement structurés).

La seule réponse qui m'ait été donnée pour l'instant est : "ça apporte une sécurité supplémentaire sur le fait qu'on ne puisse pas croiser les balises". Autrement dit, ça permet de balancer une erreur si on parse un fichier XML et qu'on trouve une séquence de type "<a><b>plop</a>". Alors oui, c'est sûr, mais à ce titre on peut introduire toute une panoplie d'autres contrôles qui vont alourdir le fichier et contribuer à sa robustesse (je sais pas moi, répéter les attributs dans les balises fermantes, ajouter un checksum du contenu de chaque balise, on peut imaginer plein d'absurdités dans le genre). Disons que ça me semble illusoire d'intégrer dans la syntaxe du fichier un moyen de contrôle aussi faible, si c'était réellement l'objectif, et de passer à coté des tonnes d'autres erreurs qu'on pourrait imaginer et qui ont tout autant de probabilités (voire bien plus) d'apparaitre.

Personnellement je ne vois que deux raisons possibles :

- Un héritage de l'HTML, indispensable pour conserver le parallèle XML/HTML/XHTML. Mais ça ne fait que décaler la question : pourquoi ce choix a-t-il été retenu pour l'HTML ?
- Une aide visuelle quand un humain lit un fichier XML, au même titre que l'indentation. Un peu comme les gens qui mettent "// if" après avoir fermé un bloc "if { ... }" dans leur code, par exemple (bien que ça me semble inutile, une bonne IDE permet de visualiser automatiquement les blocs)

Auriez-vous des hypothèses (ou des explications) à coté desquelles je serais passé ?

Zephyr (./1) :
De toutes façons quand on ferme une balise, on ne choisit pas laquelle : c'est forcément la dernière qui a été ouverte. Le fait de re-préciser son nom fait double emploi et introduit même un risque d'erreur qui n'existerait pas si un simple était suffisant

En plus de l'aide visuelle, ça protège des risques d'erreurs, non ?

Tu risques de galérer un moment si tu oublis de fermer une balise, et voir un enchainement de </> ne te montrerait pas clairement quelle balise tu es en train de fermer si tu en fermes plusieurs à la suite.
L'exigence de la répétition permet à un simpler parseur de voir précisément d'où vient l'erreur, parce qu'une balise non fermée sera immédiatement détectée. Sinon, une erreur sera constatée, mais sans qu'on puisse t'indiquer où.

Ce n'est que mon avis de non-spécialiste

Je dirais au hazard l'héritage du SGML, disont que c'est plus lisible de savoir ce qui ferme, et c'est peut etre plus simple a parser et/ou indiquer les erreurs (et c'est ce que tu dit)

Sinon oui les deux syntaxes aurait pu etre possible

Folco (./2) :

Zephyr (./1) :
De toutes façons quand on ferme une balise, on ne choisit pas laquelle : c'est forcément la dernière qui a été ouverte. Le fait de re-préciser son nom fait double emploi et introduit même un risque d'erreur qui n'existerait pas si un simple était suffisant

En plus de l'aide visuelle, ça protège des risques d'erreurs, non ?

Tu risques de galérer un moment si tu oublis de fermer une balise, et voir un enchainement de ne te montrerait pas clairement quelle balise tu es en train de fermer si tu en fermes plusieurs à la suite. L'exigence de la répétition permet à un simpler parseur de voir précisément d'où vient l'erreur, parce qu'une balise non fermée sera immédiatement détectée. Sinon, une erreur sera constatée, mais sans qu'on puisse t'indiquer où.

Boah pas plus que quand tu fermes un bloc d'instructions (avec un begin/end ou des { / }). Si tu n'indentes pas, ça sera toujours la merde, mais ça oblige au moins à visuellement bien écrire...

Dans le cas du XML, même si tu n'indentes pas, on te trouvera immédiatement la balise qui déconne. C'est ça l'avantage.

a mon avis oui c'est une des raisons, avec la similarité SGML

(parce qu'en effet techniquement ça sert à que dalle)

./2 : Justement, c'est pour ça que je laisse ouverte dans mon post la question "ok si c'est un choix de sécurité, mais dans ce cas-là pourquoi n'avoir retenu que celui-là ?". Parceque ça ne permet d'éviter que très partiellement les erreurs possibles, on aurait pu alourdir bien plus la syntaxe en ajoutant tout un tas de contrôles supplémentaires. J'aurais compris les choix "rien du tout" ou "format bourré de contrôles de cohérences", mais ce compromis ne me semble pas pertinent ^^

Je pense que c'est une manière plus simple de "formatter" le code XML.
Dans ton exemple, c'est "simple", mais imagines qu'il y ait une profondeur de 30 dans ton arbre XML avec des tags dans tous les sens. Si tu fermes les balises juste avec </>, tu ne vas plus t'y retrouver car tu ne sauras plus quelle balise elle ferme sans remonter ton code...
En plus, ça permet d'être sûr que tu te trouves au bon endroit dans ton arbre (si tu oublies un "</>", ton arbre sera décalé, et à débugger, je ne te racontes pas la galère...)

P.S: je n'ai pas lu les autres posts, si quelqu'un avait déjà souligné ce point, je m'excuse du doublon...

À défaut d'avoir lu les autres posts, tu aurais pu au moins lire le ./1 en entier ou j'explique précisément pourquoi je ne trouve pas cette justification satisfaisante

Je crois que le plus simple reste que ça découle du SGML

Oui, ça aussi c'est une hypothèse que j'ai soulevée dans le ./1, et qui change juste le sujet de la question : ok pour le XML, mais pourquoi ce choix au niveau de la spec du SGML ?

question subsidiaire: le html tel qu'inventé par tim berners lee se base sur le SGML qui existait avant , ou bien le SGML découle t il du html primitif?

dans ce cas ça pourrait être "pour être user friendly" ^^

Zephyr (./1) :
pourquoi ce choix a-t-il été retenu pour l'HTML ?

Ben parce que pour l'HTML (et le SGML) la justification que tu donnes ne tient pas : une balise fermante n'est pas obligée de correspondre à la dernière balise ouvrante vue vu que les éléments peuvent être fermés implicitement. Bon alors je ne sais pas jusqu'à quel point c'est souple, je crois que ça dépend des DTD, et quoi qu'il en soit en HTML ça n'a jamais été implémenté correctement (ou en tout cas pas par des vrais navigateurs), mais il me semble que en théorie si tu tapes par exemple <a><b><c></a> c'est équivalent à <a><b><c></c></b></a>, parce que l'imbrication des éléments est stricte donc quand tu fermes a ça ferme implicitement tout ce qui était dans a.
Enfin je dis ça sous réserve, la spec SGML est super compliquée et je l'ai pas lue en entier, mais bon ^^

De même en HTML tu n'as pas besoin de fermer l'élément <br> parce qu'il est déclaré EMPTY, c'est une contrainte stricte, il ne peut pas avoir de contenu donc il est implicitement fermé aussitôt qu'il est ouvert. Et tu as encore des possibilités de contraintes sur les éléments autorisés à l'intérieur d'un autre, par exemple un <p> ne peut pas contenir d'autres <p>, donc si tu en ouvres un alors que tu es déjà dans un autre, celui où tu étais est fermé implicitement, etc.

Après le XML est une version ultra simplifiée du SGML où ils ont viré toutes les features qui demandaient un minimum de sophistication de la part du parseur, du coup ça n'a plus trop de sens, mais bon. Comme dit bob le but principal du XML n'est absolument pas de faciliter la détection d'erreurs, c'est d'être le plus facile possible à parser

squalyl > le HTML est du SGML. En fait le SGML définit une syntaxe générale pour les documents (comment on écrit des balises ouvrantes, fermantes, etc.) mais aussi un langage pour décrire des « types de documents » dans ce qu'on appelle une DTD (document type description). Ces DTD disent quels sont les éléments possibles dans ton type de document et les diverses contraintes (quoi peut contenir quoi, etc.)
Le HTML est un type de document défini en SGML par une telle DTD. Mais c'est un type de document très simple où plein de features de SGML ne sont pas utilisées. Les balises fermantes implicites le sont cependant, au moins dans une certaine mesure.

Le SGML permet de faire un

<a><b></a></b> ce que le XML n'est pas capable de faire

ok, bonne réponse, je n'avais pas réalisé ça mais ça m'a l'air tout a fait cohérent ^^ ("ça m'a l'air" parceque je ne connais pas le SGML non plus)

c'est dommage quand même parceque ça donne une contrainte XML qui ne sert finalement pas à grand chose

Euh je suis quasiment certain que l'imbrication des éléments en SGML est *toujours* stricte, par conséquent <a><b></a></b> n'est pas valable (tu fermes un b qui n'est pas ouvert, parce qu'il a été implicitement fermé par le </a>)

Tiens, si j'avais envie de lancer un troll, je demanderais carrément l'intérêt de la syntaxe textuelle du XML/HTML/SGML, sachant que dans 99.999% des cas c'est parsé par une machine, et qu'utiliser un format texte ne fait que gaspiller de la place, et ralentir/compliquer le parsing...

(et pour ceux qui l'ignoreraient, des formats binaires sous forme d'arbre extensible arbitrairement existaient bien avant, suffit de voir l'IFF (et ses dérivés : WAV, AVI...) par exemple)

Bon voilà c'est très bien expliqué ici sur un exemple : http://www.isgmlug.org/sgmlhelp/g-sg13.htm

Où l'on comprend que les balises fermantes étaient originellement faites pour être très peu utilisées ^^

et après si ca te soule tellement tu peux essayer de passer à une autre syntaxe xml : http://groovy.codehaus.org/Creating+XML+using+Groovy's+MarkupBuilder (faut "juste" être dans une appli java)

oui enfin si c'est pour m'enfermer dans une techno, tout l'intérêt du XML est perdu, j'aurais aussi vite fait d'inventer mon propre format incompatible avec tout le reste

Zerosquare : c'était l'objectif du XML d'être modifiable facilement par un humain (donc lisible) avec un éditeur de texte tout con. Si les performances ont de l'importance dans ce que tu réalises, l'erreur c'est juste d'avoir choisi le XML comme format, mais il y a plein de domaines où il remplit parfaitement son rôle parcequ'on se tape totalement d'avoir un fichier de 100ko au lieu de 50 ^^

Bah, tu peux utiliser des expressions de type LISP à la place (ça s'appelle des S-expressions):
(pwic (plop "kikoo" (plup "texte")))

Maintenant, je ne sais pas trop si le bordel des parenthèses est plus lisible que les tags fermants.

Tu pourrais aussi utiliser le YAML. J'ai jamais eu besoin d'y avoir recours jusqu'à présent mais c'est vraiment très bon comme concept, c'est juste dommage qu'il soit pas suffisamment connu
Cela dit le XML a au moins l'avantage de te proposer l'environnement XPath, XQuery, XSLT, XML Schema ... Même si dans plein de cas spécifiques (ou moins spécifiques) il existe des alternatives meilleures (MySQL, PHP entre autres)
Sinon le côté strict, et redondant pour la fermeture des balises non vides, est très important pour l'échanges de données. Tu n'as pas besoin (alors que celà serait nécéssaire pour le SGML si je comprends bien le site que Sally a indiqué) de connaître la structure précise désirée du document (au niveau DTD) pour pouvoir interpréter l'arbre correctement, et ce même si l'arbre *correctement* parsé (donc validé en tant que XML) devait au final être mauvais vis à vis du DTD/Schéma. D'autre part, la fermeture redondante les balises, t'apporte pour toi plus d'indications sur quoi et où tu t'es foiré, mais ça te permet également de t'assurer que ton client t'envoie pas du foin quand tu demandes du gazon (Enfin si on fermait les balises avec des </> on pourrait te fournir un document en apparence correct pour ton programme, mais en réalité faux par erreur du client (un bug dans le script php qui génère le xml par exemple ^^), mais ton programme ne le saurait pas et n'aurait probablement aucun moyen de le détecter (peut être qu'un humain pourrait parfois, mais si faut faire traiter le xml par un humain à quoi sert le programme ^^))

Zephyr (./20) :
Zerosquare : c'était l'objectif du XML d'être modifiable facilement par un humain (donc lisible) avec un éditeur de texte tout con.

Je sais bien, mais je trouve justement que ce concept est pervers pour tout ce qui n'est pas fondamentalement du texte (je dirais bien que ça a sûrement un rapport avec l'état d'esprit Unixien qui fait une fixation sur le texte et qui veut utiliser les mêmes outils pour tout faire, mais on m'accuserait de troller )

Zephyr (./20) :
Si les performances ont de l'importance dans ce que tu réalises, l'erreur c'est juste d'avoir choisi le XML comme format, mais il y a plein de domaines où il remplit parfaitement son rôle parcequ'on se tape totalement d'avoir un fichier de 100ko au lieu de 50 ^^

Je suis bien d'accord avec toi (et perso c'est pas demain la veille que je m'en servirai), mais faut dire ça à ceux qui utilisent du XML pour gérer des trucs gros de plusieurs mégas, voire dizaines de mégas

GoldenCrystal (./22) :
Enfin si on fermait les balises avec des </> on pourrait te fournir un document en apparence correct pour ton programme, mais en réalité faux par erreur du client (un bug dans le script php qui génère le xml par exemple ^^), mais ton programme ne le saurait pas et n'aurait probablement aucun moyen de le détecter

Oui mais pour paraphraser le post ./1 (entre autres) de Zephyr, c'est tout à fait possible que ça se produise même en fermant les éléments avec des balises qui reprennent leur nom, alors certes *certaines* erreurs qui n'auraient pas été détectées par </> vont être détectées avec cette contrainte, mais c'est un peu aléatoire, enfin bref je vais pas répéter tout ce qu'il a dit

merci Sally (en lisant GoldenCrystal, je me suis dit "oh non, il va falloir tout réécrire une 3eme fois" )

Oué enfin je postais ça en fait je voulais case le YAML sans être complètement hors sujet
Celà dit je pense quand même que tu as en partie tort sur l'inutilité de la redondance au niveau de la fermeture des balises (c'est comme un "CRC" sur ton intention) mais j'ai pas envie d'écrire un paté (j'ai essayé mais non) alors j'en resterai là.

J'ai pas dit que la fermeture des balises était une redondance inutile, j'ai dit qu'il me semblait discutable d'avoir fait le choix d'inclure cette redondance là et aucune autre, et qu'il m'aurait semblé plus cohérent soit de ne mettre aucune redondance, soit d'introduire quelque chose d'un peu plus robuste que cette précaution très insuffisante seule, mais pas un compromis mal équilibré à mon goût.

Qu'aurais-tu proposé comme redondance ?

J'ai déjà donné deux exemples : hey, vous lisez le topic ou il faut vraiment que je c/c 3 fois chacun de mes posts ?

En plus de répéter les balises, on aurait très bien pu imaginer une répétition des arguments :

<balise attribut1="valeur1" attribut2="valeur2">
    <inner>Contenu</inner>
</balise attribut1="valeur1" attribut2="valeur2">

Si la première réflexion qui vous vient à l'esprit en voyant cet exemple est "ça sert à rien, on les a déjà dans la balise ouvrante les attributs", demandez-vous pourquoi on s'amuse à répéter les balises fermantes ("</balise>", "</inner>") alors que la remarque est la même : ça sert à rien, on sait déjà quelle balise on ferme.


On pourrait aussi très bien imaginer un checksum de chaque balise (en fonction de ses arguments, de son contenu, que sais-je), histoire de vérifier qu'il n'y a pas eu de corruption de données :

<balise@68ce89 attribut1="valeur1" attribut2="valeur2">
    <inner@965f7a>Contenu</inner>
</balise>

Je suis sûr qu'avec un minimum d'imagination on peut sortir encore tout un tas de syntaxe alternatives qui offrent bien plus de robustesse que le simple fait de répéter les balises au moment de leur fermeture (en tout cas je pourrais en sortir encore un paquet d'autres, ni plus ni moins justifiées à mes yeux que celles qui a été retenue ^^).

Bref, d'où la question : pourquoi a-t-on choisi d'introduire une redondance au niveau de la fermeture des balises et uniquement ça ? L'héritage du SGML est la seule réponse qui me semble avoir un sens, puisque je doute que ce choix au niveau du XML ait réellement été motivé par un besoin de redondance et donc de robustesse (sinon ça aurait été vraiment un choix douteux).

Bon y'a quand même un truc qui me gêne donc au moins pour ça je vais poster, c'est que tu prends jamais en compte le DTD/Schéma, qui joue un rôle énorme. Tout document XML a un DTD/Schéma, même si il est pas explicitement défini en tant que tel dans le fichier XML (c'est un tort cela dit), mais il modifie énormément ce que tu as (pas) le droit de faire dans ce (type de) document précis.
Puis garder à l'esprit que le XML dans son usage actuel est fait pour pouvoir être écrit, et être lisible (pas pour être lu, nuance ) par des humains, même si ça a déjà été dit ça fait jamais de mal
Ensuite, pour contrer l'argument (je croyais que c'était un exemple débile" au pif ? ) des attributs répétés. Les balises (nom de balise) c'est de la sémantique, et les attributs (plus souvent leur contenu, moins souvent le nom, mais c'est variable) c'est du contenu, donc en dupliquant les attributs tu dupliquerai le contenu. Et si tu prends le DTD en compte, que fais tu pour les attributs dont la valeur par défaut est utilisée, car définie dans le DTD ? Pour moi ça rend pour raison de consistance l'idée même de répéter les attributs. (sans tenir compte de leur valeur)
Pour l'histoire de checksum, c'est complètement sans rapport. Comme je l'ai dit vite fait plus haut, la redondance est une vérification d'intention, vis-à-vis celui qui a écrit le XML. En gros quand ça détecte l'erreur c'est pour te dire "Ah, si tu voulais faire ça tu as du te tromper quelque part", ou alors simplement "Espèce de boulet, tu as mal orthographié le nom de la balise", ou même "T'es un gros naze qui n'as rien compris au format". Effectivement après ça marche pas partout mais ça on es tous d'accord
Après pour le </> j'ai toujours pas envie d'écrire un roman, alors je dirais juste deux choses: 1) Pense aussi au DTD/XSD 2) Le format du document (cf DTD) joue un rôle important dans la détermination de l'utilité de la redondance.