Mais d'abord et parce que j'aime toujours savoir de quoi on parle : de quoi s'agit-il ? Qu'est-ce qui se cache derrière cette grande promesse ? Premier écueil, il peut s'y cacher plusieurs choses.

On pense tout de suite à un export complet des données de l'application et c'est souvent ce qui veut être signifié. Mais cela peut aussi être un export d'un sous-ensemble des données ou même un export régulier et/ou automatique, que j'appellerai plutôt une « publication ».

Les deux sont intéressants et l'intérêt des différents exports varie d'une application à une autre. L'export complet a un intérêt évident : sortir les données de l'application pour les traiter dans une autre. Cette autre application peut en extraire des informations, les transformer et aussi filtrer pour remplacer dans une application le manque du deuxième style d'export.

L'export d'un sous-ensemble de données permet d'éviter l'écriture d'un filtre (avec XSLT par exemple) pour traiter par une autre application des données précises à exporter de l'application. Le fait que le filtre soit fait par l'application permet de traiter moins de données, voire d'en diffuser moins si une partie d'entre elles sont confidentielles.

La publication est une petite variation sur le thème : l'export se fait, automatiquement ou non, régulièrement ou non, vers un endroit précis, sur une requête donnée et en appelant un script de transformation. L'idée principale est une publication avec mise en forme pour une consultation par navigateur Web.

Voilà donc les principales variations qui se cachent derrière « l'export XML ».

Et l'import ?

Car c'est cette question qui m'a fait débuter ce billet. Si on trouve de l'export XML dans beaucoup d'applications, l'importation de données externes est beaucoup plus rares. Et lorsque des données externes peuvent être importées, on trouve assez souvent le support de fichiers « plats » comme le CSV (valeurs séparées par virgules). On y trouve aussi, plus rarement, des imports de formats particuliers au métier de l'application (QIF ou OFX pour une application de comptabilité personnelle par exemple).

Je vois une raison assez simple pour que l'export XML soit beaucoup plus présent qu'un import XML : c'est nettement plus facile et rapide à programmer. Dans sa forme la plus bête, il suffit de parcourir les données et de les représenter sous une forme textuelle dans un fichier. Du moment que le parcours des données fonctionne, alors l'export fonctionne. La vision de certains exports par le passé me fait même dire que, parfois, il n'a pas semblé nécessaire de vérifier la validité de l'export, de le documenter ou même de le rendre pertinent.

Un import, c'est plus complexe : il faut « parser » le fichier (c'est-à-dire le lire et en extraire la structure et les informations) et le transformer en données internes. Si le format de sauvegarde de l'application n'est pas nativement XML cela nécessite, même avec l'aide des nombreuses bibliothèques DOM ou SAX existantes, un travail bien plus complexe et beaucoup plus sujets à l'erreur que l'export.

Dans le cas où l'application sauve ses données en XML, alors l'absence de l'import peut-être compensé par l'écriture d'une application externe (voire un simple filtre) qui écrira les données dans ce format directement.

Dans le cas où l'application n'offre ni import ni accès simple a ses données [1] l'application se retrouve isolée. Il n'y a pas d'autre moyen que d'entrer toutes les données directement via cette application [2]

Allez voir ailleurs...

Ce qui est étrange, c'est que les applications (ou plutôt, leurs concepteurs) donnent l'impression qu'ils font tout pour que l'on puisse migrer vers une autre application sans faciliter le contraire. On pourrait pourtant croire que, dans l'intérêt de cette application, il conviendrait de faciliter l'import des données d'une applications concurrentes. C'est ce qui est fait dans la plupart des applications de comptabilité personnelle, qui parlent le même langage et peuvent donc s'échanger des informations [3]

J'en ai déjà parlé dans un autre contexte, vouloir que ses données puissent migrer d'une solution à une autre est une demande normale pour l'utilisateur. Je disais même qu'il était essentiel pour un utilisateur ne voulant pas se faire enfermer dans une solution de vérifier qu'il avait les moyens de migrer ses données facilement.

Migrer ses données nécessite bien entendu un export, mais nécessite aussi un import de l'autre côté.

Mon application fait de l'XML !

Voilà pourquoi, une application qui annonce « supporte le XML », « exporte en XML » ou pire « utilise XML » n'annonce en fait pas grand chose. Il est nécessaire, pour comprendre ce qui est réellement permis par l'application, d'aller au delà de la présentation générale et des mises en avant des points clés, souvent plus accroches marketing que réels informations.

Notes

[1] en utilisant un format binaire non documenté et changeant d'une version à une autre par exemple.

[2] ou de demander au développeur de le faire.

[3] OFX dans ses versions 2.0 et ultérieurs est d'ailleurs un format XML.