Le format XML serait meilleur que JSON pour la mise en page d'interface utilisateur

Version imprimable

31/10/2019, 13h13
Bill Fassinou

3 pièce(s) jointe(s)

Le format XML serait meilleur que JSON pour la mise en page d'interface utilisateur

Le format XML serait meilleur que JSON pour la mise en page d'interface utilisateur,
selon Adam Stepinski, directeur de l’ingénierie chez Instawork

Les formats JSON et XML sont deux des formats de fichiers les plus utilisés dans la programmation. L’un est orienté données (JSON) et l’autre est orienté documents (XML) et ils peuvent tous les deux être utilisés pour recevoir des informations (données) d’un serveur. Selon Adam Stepinski, directeur de l’ingénierie chez Instawork, JSON peut se montrer plus utile et un meilleur choix que XML dans plusieurs domaines, mais s’il y a un domaine dans lequel XML est de loin le meilleur choix, c’est la mise en page des interfaces utilisateurs.

JSON signifie JavaScript Object Notation. C'est un format de fichier standard ouvert utilisé pour les communications navigateur-serveur. C'est un format de données indépendant du langage. XML signifie Extensible Markup Language. XML représente un ensemble de règles qui aident les utilisateurs à coder des documents dans un format lisible par l'homme et par la machine. Pour cette dernière raison, Adam Stepinski, directeur de l’ingénierie chez Instawork et son équipe pensent que le format XML est le meilleur choix dans la conception des interfaces utilisateurs.

Pièce jointe 514230

Stepinski et son équipe ont développé Hyperview XML (HXML), un nouveau format hypermédia basé sur XML et un client React Native pour le développement d'applications mobiles pilotées par serveur. Hyperview XML est un format hypermédia utilisé pour définir les écrans (interfaces utilisateurs) d'applications mobiles. HXML fournit un ensemble de balises et d'attributs qui permettent de définir la disposition d'un écran, le style et les interactions utilisateurs disponibles. Les comportements en HXML définissent les actions qui doivent se produire dans l'application.

Ces actions sont une réponse à un déclencheur basé sur l'utilisateur. Les comportements peuvent être spécifiés soit comme attributs sur d'autres éléments HXML, soit comme un élément enfant <behavior>. Selon l’équipe de développement de l’outil, sur le Web, les pages sont rendues dans un navigateur en récupérant le contenu HTML à partir d'un serveur. Avec HXML, les écrans sont rendus dans votre application mobile en récupérant du contenu Hyperview XML depuis un serveur. La conception de HXML reflète l'interface utilisateur et les modèles d'interaction des interfaces mobiles d'aujourd'hui.

Selon Stepinski, chaque format permet de faire des compromis en matière de codage, de flexibilité et d'expressivité pour répondre au mieux à un cas d'utilisation spécifique. Autrement dit, un format optimisé pour la taille utilisera un encodage binaire qui ne sera pas lisible par l'homme, un format optimisé pour l'extensibilité prendra plus de temps à décoder qu'un format conçu pour un usage restreint et enfin un format conçu pour des données plates (comme CSV pour Comma-separated values) aura du mal à représenter des données imbriquées.

Outre les propriétés intrinsèques d'un format, Stepinski explique aussi que des facteurs externes peuvent influencer ses cas d'utilisation pratique, tels que la popularité du format auprès des développeurs cibles ou le support des bibliothèques dans les langages de programmation souhaités. « Lorsqu'ils choisissent un format de fichier à utiliser dans un projet logiciel, les ingénieurs en logiciel choisissent celui qui présente le meilleur équilibre entre les caractéristiques et les facteurs externes pour la situation », a-t-il déclaré dans un billet explicatif.

Pièce jointe 514238

Pour Stepinski, JSON représente un meilleur choix que XML dans l’utilisation des listes. Le format XML est plus utile pour exploiter les arbres

D’après Stepinski, par exemple, JSON représente un meilleur choix que XML dans l’utilisation des listes. Par contre, le format XML sera plus utile pour exploiter les arbres. Il estime que JSON est bien plus adapté que XML pour représenter des listes d'objets aux propriétés complexes. La syntaxe clé/valeur de l'objet JSON facilite les choses. En revanche, la syntaxe des attributs XML ne fonctionne que pour des types de données simples. L'utilisation d'éléments enfants pour représenter des propriétés complexes peut entraîner des incohérences ou une verbosité inutile.

Pour lui, JSON excelle dans la représentation d'une collection d'objets homogènes, où les propriétés des objets peuvent être des types de données composites. D’un autre côté, XML excelle dans la représentation d'arbres avec des objets hétérogènes, où les propriétés des objets sont des types de données simples. Dans ce cas de figure, lorsque l’on voit les interfaces utilisateurs comme des arbres, Stepinski dit que XML est le format de représentation le mieux adapté. Selon Stepinski, les dispositions de l'interface utilisateur sont des arbres.

Pièce jointe 514252
Adam Stepinski

C’est la raison pour laquelle ils ont conçu Hyperview en se basant sur le format XML existant. Stepinski a expliqué que les arborescences de composants sont le meilleur moyen de représenter les mises en page de l'interface utilisateur et que tous les principaux frameworks d'interface utilisateur utilisent une arborescence de composants. D’après lui, Xcode fournit même une vue 3D éclatée qui met réellement en évidence l'arborescence sous-jacente d'une interface : chaque composant a un composant parent, et tout se transforme en un composant racine partagé.

« Les structures de l'interface utilisateur sont représentées sous forme d'arbres de composants. Et XML est idéal pour représenter des structures arborescentes. C'est un mariage fait au paradis ! En fait, les frameworks d'interface utilisateur les plus populaires dans le monde (HTML et Android) utilisent la syntaxe XML pour définir les modèles », a déclaré Stepinski. Il donne l’exemple de React, le framework de composants graphiques de Facebook, qui recommande aussi de définir l'interface utilisateur des composants à l'aide de JSX, un format semblable à XML.

D’après lui, même si l'utilisation de JSX nécessite l'apprentissage d'une nouvelle syntaxe non-JS et l'ajout d'une étape de transplantation au processus de compilation, les concepteurs de la bibliothèque estiment que cela vaut la peine d'utiliser XML. « Les arbres sont une représentation puissante pour les agencements d'interface utilisateur. Ils fournissent naturellement des regroupements de composants, permettant aux concepteurs et aux développeurs d'utiliser des abstractions de plus haut niveau », a-t-il expliqué, dans son billet.

« Lorsque nous avons besoin de cacher, afficher ou animer une section de l'écran, nous n'avons pas besoin de changer l'état de chaque composant de la section. Nous pouvons plutôt changer l'état du composant parent unique qui contient chaque élément de l'interface utilisateur de la section. Lors de la modification d'un composant, nous n'avons qu'à nous préoccuper de ce qui se trouve dans son sous-arbre, et non de ce qui se passe à des niveaux supérieurs », a-t-il conclu.

Source : Adam Stepinski

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous des arguments de Stepinski ? Êtes-vous du même avis ou pas ? Pourquoi ?
:fleche: Quel type de format préférez-vous et pourquoi ?

Voir aussi

:fleche: JavaScript : faut-il privilégier les transformations XML à JSON et aux Frameworks ? Partagez vos avis

:fleche: React : la version 16.8 de la bibliothèque JavaScript est disponible et embarque une version stable des Hooks

:fleche: Une interface utilisateur évidente est souvent la meilleure interface utilisateur. Concevez des interactions claires plutôt qu'intelligentes et les utilisateurs suivront, conseille Google Design

:fleche: Google Chrome apporte des modifications à l'interface utilisateur de son navigateur, les changements sont disponibles sur Chrome Canary
31/10/2019, 14h46
Sodium

Heu ben oui... idéalement avec du XML itérant sur des données JSON d'ailleurs comme c'est le cas d'Angular ou Vuejs (je ne parlerai pas de React car c'est sale).

Il y avait un doute à ce sujet ?
31/10/2019, 15h29
Kulvar

JSON n'est pas faire pour présenter les données.
XML (et HTML) si, encore heureux qu'il soit meilleur à ça.

Ce serait bien de citer plus d'exemples de l'article original.

Exemple où JSON bat XML

Code propre en JSON :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
[
  {
    "first_name": "Michael",
    "last_name": "Scott",
    "favorite_movies": [ "Diehard", "Threat Level Midnight" ]
  },
  {
    "first_name": "Dwight",
    "last_name": "Schrute",
    "favorite_movies": [ "The Crow", "Wedding Crashers" ]
  },
  {
    "first_name": "Pam",
    "last_name": "Beesly",
    "favorite_movies": [ "Legally Blonde" ]
  }
]

Code naze en XML : on encode une liste à la main avec la virgule comme séparateur.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
<Users>
  <User
    first="Michael"
    last="Scott"
    favoriteMovies="Diehard, Threat Level Midnight" />
  <User
    first="Dwight"
    last="Schrute"
    favoriteMovies="The Crow, Wedding Crashers" />
  <User
    first="Pam"
    last="Beesly"
    favoriteMovies="Legally Blonde" />
</Users>

Attention ! Comment gérer le cas où un titre de film contient une virgule ? Il n'y avait pas besoin de gérer ce cas dans le JSON précédent.

Code correct mais verbeux en XML :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<Users>
  <User first="Michael" last="Scott">
    <Movie>Diehard</Movie>
    <Movie>Threat Level Midnight</Movie>
  </User>
  <User first="Dwight" last="Schrute">
    <Movie>The Crow</Movie>
    <Movie>Wedding Crashers</Movie>
  </User>
  <User first="Pam" last="Beesly">
    <Movie>Legally Blonde</Movie>
  </User>
</Users>

Là, le JSON était meilleur, car plus lisible.

Exemple où XML bat JSON

Arborescence concise en XML :

Code:

1
2
3
4
5
6
7
8
9
 
<Employee name="Michael Scott" title="Regional Manager">
  <Employee name="Dwight Schrute" title="Ass. Regional Mgr" />
  <Employee name="Jim Halpert" title="Head of Sales">
    <Employee name="Andy Bernard" title="Sales Rep" />
    <Employee name="Phyllis Lapin" title="Sales Rep" />
  </Employee>
  <Employee name="Pam Beesly" title="Office Administrator" />
</Employee>

Arborescence en JSON, plus verbeuse à cause de l'indentation canonique :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
{
  "name": "Michael Scott",
  "title": "Regional Manager",
  "reports": [
    {
      "name": "Dwight Schrute",
      "title": "Ass. Regional Mgr"
    },
    {
      "name": "Jim Halpert",
      "title": "Head of Sales",
      "reports": [
        {
          "name": "Andy Bernard",
          "title": "Sales Rep"
        },
        {
          "name": "Phyllis Lapin",
          "title": "Sales Rep"
        }
      ]
    },
    {
      "name": "Pam Beesly",
      "title": "Office Administrator"
    }
  ]
}

Citation:

Envoyé par Pyramidev

Ce serait bien de citer plus d'exemples de l'article original.

Exemple où JSON bat XML

Code propre en JSON :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
[
  {
    "first_name": "Michael",
    "last_name": "Scott",
    "favorite_movies": [ "Diehard", "Threat Level Midnight" ]
  },
  {
    "first_name": "Dwight",
    "last_name": "Schrute",
    "favorite_movies": [ "The Crow", "Wedding Crashers" ]
  },
  {
    "first_name": "Pam",
    "last_name": "Beesly",
    "favorite_movies": [ "Legally Blonde" ]
  }
]

Code naze en XML : on encode une liste à la main avec la virgule comme séparateur.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
<Users>
  <User
    first="Michael"
    last="Scott"
    favoriteMovies="Diehard, Threat Level Midnight" />
  <User
    first="Dwight"
    last="Schrute"
    favoriteMovies="The Crow, Wedding Crashers" />
  <User
    first="Pam"
    last="Beesly"
    favoriteMovies="Legally Blonde" />
</Users>

Attention ! Comment gérer le cas où un titre de film contient une virgule ? Il n'y avait pas besoin de gérer ce cas dans le JSON précédent.

Code correct mais verbeux en XML :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<Users>
  <User first="Michael" last="Scott">
    <Movie>Diehard</Movie>
    <Movie>Threat Level Midnight</Movie>
  </User>
  <User first="Dwight" last="Schrute">
    <Movie>The Crow</Movie>
    <Movie>Wedding Crashers</Movie>
  </User>
  <User first="Pam" last="Beesly">
    <Movie>Legally Blonde</Movie>
  </User>
</Users>

Là, le JSON était meilleur, car plus lisible.

Exemple où XML bat JSON

Arborescence concise en XML :

Code:

1
2
3
4
5
6
7
8
9
 
<Employee name="Michael Scott" title="Regional Manager">
  <Employee name="Dwight Schrute" title="Ass. Regional Mgr" />
  <Employee name="Jim Halpert" title="Head of Sales">
    <Employee name="Andy Bernard" title="Sales Rep" />
    <Employee name="Phyllis Lapin" title="Sales Rep" />
  </Employee>
  <Employee name="Pam Beesly" title="Office Administrator" />
</Employee>

Arborescence en JSON, plus verbeuse à cause de l'indentation canonique :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
{
  "name": "Michael Scott",
  "title": "Regional Manager",
  "reports": [
    {
      "name": "Dwight Schrute",
      "title": "Ass. Regional Mgr"
    },
    {
      "name": "Jim Halpert",
      "title": "Head of Sales",
      "reports": [
        {
          "name": "Andy Bernard",
          "title": "Sales Rep"
        },
        {
          "name": "Phyllis Lapin",
          "title": "Sales Rep"
        }
      ]
    },
    {
      "name": "Pam Beesly",
      "title": "Office Administrator"
    }
  ]
}

Sauf que dans tes exemples tu mélanges données et meta-données.
En xml, les attributs sont fait pour les méta-données, les données sont dans les balises, mais ça devient plus verbeux que du json.
En json, il n'est pas possible d'avoir des méta-données.

31/10/2019, 18h12
Sodium

Oui... et ? Pourquoi faudrait-il absolument des meta-données ? JSON permet de faire ce que l'on veut, rien ne t'empêche de créer une clé metadata si ça te change...

Je dirais même l'inverse, JSON contient essentiellement des meta-données.
31/10/2019, 18h42
pdeville

Json vs XML

JSon est parfaitement adapté à la gestion des données structurées et fournit un format peu verbeux.

XML bien que plus verbeux permet de representer des données non structurérs avec CDATA.

Un des avantages de JSON sur XML est qu'il est plus facile à lire par un programme.
Pour la lecture par un humain, comme l'a montré l'auteur de l'article original, ça dépend des cas.

J'en profite pour souligner que, parmi les formats les plus utilisés pour structurer des données arbitraires, il y a aussi le YAML qui est une extension du JSON qui, par rapport à JSON, est plus facile à lire par un humain, mais moins facile à lire pour un programme.

Prenons l'exemple du JSON suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 { "name": "Michael Scott", "title": "Regional Manager", "reports": [ { "name": "Dwight Schrute", "title": "Ass. Regional Mgr" }, { "name": "Jim Halpert", "title": "Head of Sales", "reports": [ { "name": "Andy Bernard", "title": "Sales Rep" }, { "name": "Phyllis Lapin", "title": "Sales Rep" } ] }, { "name": "Pam Beesly", "title": "Office Administrator" } ] }
Voici une réécriture en YAML :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 name: Michael Scott title: Regional Manager reports: - name: Dwight Schrute title: Ass. Regional Mgr - name: Jim Halpert title: Head of Sales reports: - name: Andy Bernard title: Sales Rep - name: Phyllis Lapin title: Sales Rep - name: Pam Beesly title: Office Administrator

31/10/2019, 22h44
defZero

:ptdr: Le mec trouve XML plus adapter que JSON parce que son équipe vient de créer un UI Engine qui prend du XML pour faire du rendue dynamique/interprété, c'est tout, il n'y a pas à débattre 3 ans.

Chacun peut bien utiliser l'outil qui convient le mieux à son projet. ;)

P.S. : Et dire qu'en 95 on utilisés principalement Delphi pour définir une interface en "client lourd"*.
C'était typer, compiler et juste ça fonctionnait bien.
Maintenant les gens utilise XML/JSON/YAML/...etc pour décrire leurs interfaces et interpréter le contenue à chaque utilisation.
Je vois ça comme une régression, pas un progrès.

* Vous remarquerez le "client lourd" entre guillemet parce qu’un client léger de 2019 pèse facile dans les 100-200MB. :aie:
01/11/2019, 00h53
LeBressaud

Citation:

Envoyé par Sodium

Je dirais même l'inverse, JSON contient essentiellement des meta-données.

Sur un forum ça passe presque inaperçu, évite de dire ça en réunion avec des gens qui s'y connaisse un minimum..

JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu. Aucun rapport avec des méta-données
01/11/2019, 02h01
matthius

Je crois que Free Pascal utilise le XML pour les processeurs Intel.
01/11/2019, 02h11
Pyramidev

Citation:

Envoyé par LeBressaud

JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu.

JSON distingue plusieurs types de données. Par exemple, les booléens ne sont pas des nombres qui ne sont pas des chaînes.
De base, dans du JSON, tout comme dans du XML, on peut mettre n'importe quoi n'importe comment.
Et si on veut écrire un schéma de validation pour restreindre ce que l'on a le droit d'écrire, tout comme il existe des schémas XML, il existe aussi des schémas JSON.
01/11/2019, 10h12
Sodium
Citation:

Envoyé par LeBressaud

Sur un forum ça passe presque inaperçu, évite de dire ça en réunion avec des gens qui s'y connaisse un minimum..

JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu. Aucun rapport avec des méta-données

Sur un forum ça passe presque inaperçu, évite de dire ça en réunion avec des gens qui s'y connaisse un minimum..

Définition des métadonnées : Les métadonnées synthétisent des informations élémentaires sur les données, elles facilitent la recherche et la manipulation d'instances de données particulières. L'auteur, la date de création, la date de modification et la taille du fichier en sont des exemples. Les métadonnées et leur corollaire, le filtrage des données, aident à localiser un document spécifique.
Code:

1 2 3 4 5 "person": { "age": 27 "firstname": John, "lastName": Doe }
Je ne vois pas en quoi ça ne correspondrait pas à la définition.

Citation:

Envoyé par Sodium

JSON permet de faire ce que l'on veut, rien ne t'empêche de créer une clé metadata

Je suis d'accord avec ce passage.

Citation:

Envoyé par Sodium

Je dirais même l'inverse, JSON contient essentiellement des meta-données.

Avoir plus de meta-données que de données serait bizarre. Les données normales, ce sont les données principales que l'on veut stocker. Les meta-données, ce sont des informations complémentaires. Et il n'y a aucune raison qu'il y en ait plus en JSON qu'en XML.

Citation:

Envoyé par kbadache

Sauf que dans tes exemples tu mélanges données et meta-données.
En xml, les attributs sont fait pour les méta-données, les données sont dans les balises, mais ça devient plus verbeux que du json.

Au début de l'article original, on peut lire :

Citation:

When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:

“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”

L'auteur défend le XML en indiquant qu'il y a des cas où on peut le rendre plus lisible que le JSON.
Sauf que, dans les cas où le XML peut être plus lisible que le JSON, il faut tirer profit des attributs.
Si on réserve les attributs aux méta-données, alors on se retrouve avec du XML très verbeux comme ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 <?xml version="1.0" encoding="UTF-8" ?> <root> <name>Michael Scott</name> <title>Regional Manager</title> <reports> <name>Dwight Schrute</name> <title>Ass. Regional Mgr</title> </reports> <reports> <name>Jim Halpert</name> <title>Head of Sales</title> <reports> <name>Andy Bernard</name> <title>Sales Rep</title> </reports> <reports> <name>Phyllis Lapin</name> <title>Sales Rep</title> </reports> </reports> <reports> <name>Pam Beesly</name> <title>Office Administrator</title> </reports> </root>
Et là, on donne raison aux détracteurs inconditionnels du XML : pourquoi choisir encore ce vieux format obsolète plus difficile à lire que du JSON, à la fois pour un humain et pour un programme ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 { "name": "Michael Scott", "title": "Regional Manager", "reports": [ { "name": "Dwight Schrute", "title": "Ass. Regional Mgr" }, { "name": "Jim Halpert", "title": "Head of Sales", "reports": [ { "name": "Andy Bernard", "title": "Sales Rep" }, { "name": "Phyllis Lapin", "title": "Sales Rep" } ] }, { "name": "Pam Beesly", "title": "Office Administrator" } ] }