Discussion :

[thelvin]

De ce que je peux en voir, le but n'est absolument pas de rendre XML plus court, mais plus simple.
Et je suis plutôt d'accord avec l'idée, mais elle arrive un peu tard : nous avons une bonne décennie de XML compliqué à gérer, maintenant.

Plus simple :
- Pas de DTD incluse ou de DTD tout court : s'il y a un doctype, il ne fait que donner le nom du premier élément, comme en HTML5 (et donc il n'a aucun intérêt et n'est là que pour compatibilité, oui.) Ça signifie pas de déclaration d'entités, et donc les seuls références d'entités qu'on puisse avoir, c'est < > & ' et ". Ça signifie aussi pas de valeur par défaut pour les attributs.
=> C'est pas dommage. Les entités externes et internes avaient des intérêts, mais les outils les géraient trop mal, c'était la merde. Les valeurs par défaut d'attributs, c'était juste complètement chiant. Et puis franchement c'est trop compliqué.

- Pas de déclaration XML. Ça servait essentiellement à indiquer le charset, qui du coup doit être utf-8 et puis c'est tout.
=> Ça élude le problème.

- Pas de CDATA.
=> C'est gadget, mais bon, c'est plus simple.

- Syntaxe simplifiée des processing instructions.
=> Je me demande si c'est pas une erreur... Ça casse la compatibilité avec l'existant. D'un autre côté, personne n'utilise les processing instructions autrement... Et presque personne ne les utilise tout court. Moi je les aurais carrément virées.
Me semble pas très intéressant.

Réponses aux questions habituelles :

- Pourquoi pas JSON ?
=> Il gère très mal les flux à la HTML
=> Il n'est pas extensible
=> Il est moins explicite
Si JSON est mieux pour votre besoin, servez-vous en. Sinon, non.

- Pourquoi ne pas standardiser JSON ?
JSON est déjà standardisé, simplement, de nombreux auteurs de bibliothèques ne savent pas ce qu'ils font. Même si ce n'est pas mérité, les endroits où on ne jure que par JSON ne sont pas franchement des modèles de rigueur. Pas de chance, c'est comme ça. On a les nôtres du côté XML aussi.

- Pourquoi pas Yaml ?
=> Il ne gère pas les flux à la HTML
=> Il n'est pas extensible
=> Son modèle d'imbrication est très limité.
=> Que ça nous plaise ou non, les gens sont plus perturbés par cette syntaxe que par les autres (qui, au contraire, leur vient naturellement.) À quoi ça sert d'attirer les ennuis ?
Si Yaml résout vos problèmes, servez-vous en. Sinon, non.

[thelvin]

Tiens je viens de me rendre compte qu'ils modifient aussi la gestion des namespaces. Petit tour de ce que j'ai vu :

- Unification des namespaces : deux namespaces sont indentiques si leurs URI contiennent les mêmes caractères dans le même ordre, et non pas s'ils se résolvent vers la même URI absolue.
=> C'est évident que ça aurait dû être comme ça depuis le début -_-°.

- Pas de préfixe pour les éléments : on peut donner un namespace aux éléments, mais ils doivent obligatoirement être dans le namespace par défaut.
=> Euh... Je suis d'accord que c'est plus simple à programmer, mais bon sang, les documents qui utilisent plusieurs namespaces, ça va être bien illisible, là. Je souhaite du courage à ceux qui voudraient faire du XSLT avec ça.

- Pour les namespaces d'attributs, ça fonctionne comme avant.
=> Du coup l'intérêt d'avoir changé les namespaces d'éléments.... 'Fin bon.

[vampirella]

Yaml c'est de la merde en boite.

Allons, pas tant de hargne, c'est juste beaucoup moins strict, et donc moins "progamer-friendly", mais je partage ta déconsidération de Yaml (pour les bonnes raisons qu'a évoqué thelvin)

Tout à fait, est qu'est-ce que du XML sans balises fermantes nommées ?

<bob>texte</bob> => <bob texte >

Du LISP !

(bob texte)

Je verrais plutôt quelque chose comme ci-dessous (pour les raisons fournis) :
<bob attribut="truc">texte
saut de ligne</>

Il est vrai qu'un XML correctement formé n'accepte pas de balises à cheval (balise fermé au milieu d'une autre balise ouverte et non encore fermée). Ceci dit, le fait d'ajouter le nom dans la balise fermante permet d'être plus compréhensible par les humains, bien que cela soit en soi inutile en effet.

[Paul TOTH]

...
Il est vrai qu'un XML correctement formé n'accepte pas de balises à cheval (balise fermé au milieu d'une autre balise ouverte et non encore fermée). Ceci dit, le fait d'ajouter le nom dans la balise fermante permet d'être plus compréhensible par les humains, bien que cela soit en soi inutile en effet.

ça permet aussi aux balises de se chevaucher

j'ai fait un site de type Wiki qui utilise une syntaxe qui lui est propre, elle est basée sur une notation du type

(code:valeur)

...exemple pour le gras c'est le code "b"

(b:ceci est en gras)

...du coup impossible de faire se chevaucher des balises

(b:ceci est en gras et (i:ceci en gras et italique), de nouveau en gras)

et si le "code" est invalide, le tout est traité comme de simples parenthèses

[thelvin]

ça permet aussi aux balises de se chevaucher

Ouais enfin, XML n'autorise pas le chevauchement, même si sa syntaxe permet de l'écrire.

Et puis bon, à part pour faire son artiste, c'est pas souvent qu'il aurait été utile de pouvoir chevaucher des balises.

[Paul TOTH]

Ouais enfin, XML n'autorise pas le chevauchement, même si sa syntaxe permet de l'écrire.

Et puis bon, à part pour faire son artiste, c'est pas souvent qu'il aurait été utile de pouvoir chevaucher des balises.

tout à fait, bien qu'on puisse comprendre qu'en HTML on soit tenté d'écrire <b>G<i>G + I</b> I</i>...

mais à mes yeux c'est une faiblesse du format.