Discussion :

[Hinault Romaric]

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.

Rejoindre le groupe de travail

Liste des membres


Et vous ?

Que pensez-vous de ce futur standard ?

[ScroudaF]

Pourquoi ne pas adopter JSON?

[MicroJoe]

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.

[Calmacil]

Pour des raisons de compatibilité.

[Lunatikzx]

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

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

[supertonic]

Et Yaml dans tout ça ?

[b4ptx]

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

hum...

[Tab]

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

[Bousk]

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.

[Nithril]

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.

[Nithril]

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.

[bugsan]

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

[MicroJoe]

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.

[Camille_B]

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)

[Nithril]

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

[Paul TOTH]

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 :

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

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.

[kolodz]

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

[sybil]

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

[MicroJoe]

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 :

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

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