Le W3C crée le groupe communautaire pour MicroXML

Le standard qui pourra remplacer XML quand celui-ci est trop volumineux et complexe

Le 2012-07-20 13:18:50, par Hinault Romaric, Responsable .NET

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 ?

Discussion forum

25 commentaires

Calmacil
Membre régulier

Pour des raisons de compatibilité.

le 20/07/2012 à 13:50
Xinu2010
Membre averti

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

le 20/07/2012 à 14:23
ScroudaF
Futur Membre du Club

Pourquoi ne pas adopter JSON?

le 20/07/2012 à 13:34
b4ptx
Futur Membre du Club

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

hum...

le 20/07/2012 à 14:37
thelvin
Modérateur

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.

le 22/07/2012 à 21:38
bugsan
Membre confirmé

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

le 20/07/2012 à 17:32

Paul TOTH

Expert éminent sénior

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.

le 21/07/2012 à 16:26

MicroJoe
Membre du Club

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.

le 20/07/2012 à 13:47
Lunatikzx
Nouveau membre du Club

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

le 20/07/2012 à 14:20
supertonic
Membre averti

Et Yaml dans tout ça ?

le 20/07/2012 à 14:35

Poster une réponse