Je reviens sur une partie vue très brièvement dans l'article précédent lorsque je citais le classique « Cette application exporte en XML » au rang des arguments bien placés dans la liste des possibilités d'une application.

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 etc'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 styled'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 navigateurWeb.

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 del'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 leCSV (valeurs séparées par virgules). On y trouve aussi, plus rarement, des imports de formats particuliers au métier del'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èquesDOM 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 del'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¹ 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².

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

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