Le W3C crée le groupe communautaire pour MicroXML

Le W3C crée le groupe communautaire pour MicroXML
Le standard qui pourra remplacer XML où celui-ci est trop volumineux et complexe


Le W3C (World Wide Web Consortium), l’organisme de normalisation des standards du Web, vient d’annoncer la formation d’un groupe de travail communautaire pour la norme MicroXML.

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, son caractère verbeux (qui le rend trop lourd) peut rapidement devenir un problème pour la bande passante et les dispositifs dont les ressources sont limitées (smartphones, tablettes, etc.).

Le MicroXML (qui n’est pas destiné à remplacer XML) est un fragment de la spécification XML, dont l’objectif est d’être moins volumineux, plus facile à utiliser et compatible avec XML. MicroXML pourra ainsi être utilisé dans les situations où le XML est considéré comme trop volumineux ou complexe.

La spécification Micro XML décrit un ensemble de règles permettant de définir des langages de balisages (des langages ayant chacun son vocabulaire et sa grammaire) destinés à être utilisés pour la définition des données objets, et de préciser également le comportement de certains modules logiciels qui y accèdent.

Le groupe de travail communautaire MicroXML a été créé par le W3C afin de permettre aux personnes intéressées par le futur standard (internes ou externes au W3C) de s’impliquer dans son processus de normalisation.

Les gourous de XML dont James Clark (ancien responsable technique de la norme XML au W3C) et John Cowan (ancien responsable de Google au sein du W3C et à l’origine d’une partie du cahier de charge de MicroXML) font déjà partie du groupe de travail.

Toute personne intéressée par ce futur standard de représentation des données peut s’inscrire au groupe de travail afin d’apporter sa contribution à la construction de la norme.

:fleche: Rejoindre le groupe de travail

:fleche: Liste des membres


Et vous ?

:fleche: Que pensez-vous de ce futur standard ?

Pourquoi ne pas adopter JSON?

Citation:

---

Pourquoi ne pas adopter JSON?

---

Peut-être parce-qu'ils n'ont pas la même structuration et ne partent pas sur les mêmes principes ? (par exemple, en JSON les nombres sont typés comme tel alors qu'en XML tout est chaînes de caractères)
Après, peut-être que je me trompe et que µXML compte reprendre les mêmes principes que JSON et dans ce cas là ce serait effectivement réinventer la roue.

Pour des raisons de compatibilité.

Le W3c est un peu comme Gary Bettman de la LNH en amérique,
Quand ils savent que quelque chose ne marche pas ils l'édulcore parce que c'est leur idée. Le format XML tout comme le dom sont complexe et rempli de non sens. Standardiser JSON enfin ... Douglas Crockford serait heureux...

Je suis en train de lire le draft, pour l'instant je ne vois pas de différence avec du xml, il y a même les namespace. En fait c'est un xml plus permissif, mais dans ce cas je ne vois pas en quoi ça serait moins volumineux que du xml classique.

http://ccil.org/~cowan/MicroXML.html

Et Yaml dans tout ça ?

"MicroXML, le standard qui pourra remplacer XML"
"Le MicroXML (qui n’est pas destiné à remplacer XML)"

hum...

Citation:

---

Envoyé par Xinu2010

Je suis en train de lire le draft, pour l'instant je ne vois pas de différence avec du xml, il y a même les namespace.

---

Mon seul espoir réduit à néant :cry: je lirais quand même le draft plus tard.

J'espère que ça peut le faire, j'aime bien manipuler du XML mais µXML pourrait apporter un vrai plus en terme de poids.

Citation:

---

Envoyé par ScroudaF

Pourquoi ne pas adopter JSON?

---

J'espère que µXML conservera de la lisibilité (quitte à adopter l'acronyme XML) qui fait souvent défaut à du JSON.

Citation:

---

Envoyé par MicroJoe

Peut-être parce-qu'ils n'ont pas la même structuration et ne partent pas sur les mêmes principes ? (par exemple, en JSON les nombres sont typés comme tel alors qu'en XML tout est chaînes de caractères)
Après, peut-être que je me trompe et que µXML compte reprendre les mêmes principes que JSON et dans ce cas là ce serait effectivement réinventer la roue.

---

Quand le JSON est sérialisé, le nombre est lui aussi dans un format texte.

Citation:

---

Envoyé par ScroudaF

Pourquoi ne pas adopter JSON?

---

Ce n'est pas la meme cible ni le même usage. Déjà JSON n'est pas non plus un format très concis. Ensuite XML est fonctionnellement bcp plus riche que le JSON.

En XML le gros de l'overhead est du aux balises fermantes : elles sont nommées alors que cela n'apporte rien ...

Citation:

---

Envoyé par Nithril

Quand le JSON est sérialisé, le nombre est lui aussi dans un format texte.

---

Tu parles de la sérialisation à l'aide d'un programme ? Quand je le fait avec Python, j'ai bien les formats de données (texte, nombre, booléen, etc.) qui sont respectés.
Mais on s'éloigne un peu du sujet. ;)

Citation:

---

En XML le gros de l'overhead est du aux balises fermantes : elles sont nommées alors que cela n'apporte rien ...

---

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

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

Du LISP !

(bob texte)

Citation:

---

Envoyé par MicroJoe

Tu parles de la sérialisation à l'aide d'un programme ? Quand je le fait avec Python, j'ai bien les formats de données (texte, nombre, booléen, etc.) qui sont respectés.
Mais on s'éloigne un peu du sujet. ;)

---

Quand tu serializes ton json, l'entier 10 est bien écrit "10" et pas sa représentation sur 4 octets. Mais 10 c'est exactement quoi comme type ?

Le XML via schema peut dire que 10 c'est un entier, un flottant...

dans le genre ultra compact il y a le Protocol Buffer de Google, mais il impose que la lecteur sache ce qu'il risque de trouver dans le flux. Les noeuds sont en effet juste identifié par un nombre prédéterminé pour ce buffer. Mais je trouve le principe très intéressant.

ça se fait en deux temps, le format est défini dans un langage spécifique où des "id" sont affectés aux champs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

message Person { required string name = 1; required int32 id = 2; optional string email = 3;   enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; }   message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; }   repeated PhoneNumber phone = 4; }

---

celui-ci est "compilé" en code source C, Java, etc... qui permet de sérialiser cette structure de façon la plus compact possible, notamment les noms sont remplacés par leur ID.

Je peux me planter, mais dans leur draft il est indiquer que le µXML sera obligatoirement en UTF-8. Ça fait déjà 17 caractères en moins, par XML.
Et éviter de gérer les encodages différents.
A voir les autres petites différences...

il veulent faire un xml qui soit concis comme un json.

Citation:

---

Envoyé par Nithril

Quand tu serializes ton json, l'entier 10 est bien écrit "10" et pas sa représentation sur 4 octets. Mais 10 c'est exactement quoi comme type ?

---

N'empêche que c'est différencié d'un type string auquel, en JSON, sera obligatoirement ajouté des guillemets (doubles).

Code:

---

1 2 3

>>> import json >>> json.dumps({'string': 'value', 'int': 10}) '{"int": 10, "string": "value"}'

---

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 &lt; &gt; &amp; &apos; et &quot;. Ç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.

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.

Citation:

---

Envoyé par sybil

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)

Citation:

---

Envoyé par Camille_B

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.

Citation:

---

Envoyé par vampirella

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

Citation:

---

Envoyé par Paul TOTH

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

Citation:

---

Envoyé par thelvin

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.