XML trop lourd

Thibault Ducray (ex-collègue) a écrit il ya quelques temps un article exprimant son point de vue sur le bon et le mauvais XML. Cet article est intéressant, mais pour ma part, le problème de taille du XML, sa verbosité, ne nécessite pas d'inviter un nouveau langage simplifié déclaratif.

Aujourd'hui, le problème principal dans le traitement de l'information n'est pas ni le stockage (un disque dur de 500 Gigaoctets vaut moins de 150€), ni le temps de traitement (processeurs > 2000 Mhz, processeur multicoeurs, etc...), mais les entrées-sorties. Pour résoudre la verbosité d'XML qui est donc un problème pour les échanges, il suffit de le compresser et décompresser à la volée avec par exemples des algorithmes sans perte type Lempel-Ziv et autres.

La bonne nouvelle est que ceux-ci (zip, gzip) sont directement supportés par tous les OS et même les échanges HTTP. Le coût de compression/décompression par le CPU reste négligeable par rapport au cout de transfert I/O, particulièrement à partir/vers le réseau.

Il est d'ailleurs souvent "gratuit", car sinon le CPU est de toute façon bloqué en attente des I/O. C'est moins vrai sur les serveurs, mais ce surcoût est largement compensé par le hardware et la loi de Moore.

Le principal défaut d'XML est qu'il ne sait véritablement transmettre de l'information que sous forme d'arbre. Dans la plupart des cas, il est donc nécessaire de transformer l'information métier en une projection arborescente forcément réductrice.