Vous l'avez tous lu, Office Open XML, le format XML de Microsoft pour stocker des documents bureautiques, a été approuvé comme standard.

J'en ai profité pour lire un peu des articles dessus. Hé bien, on est pas sorti de l'auberge. Le standard fait plus de 6000 pages (à comparer avec les 700 pages d'ODF). Il a été approuvé en un temps record.

Plein de gros morceaux obsolètes

Il contient des tas de choses obsolètes, issues de bugs des logiciels Microsoft, et qui n'auraient jamais dû se trouver dans un format standard. Citons notamment :

  • Les dates dans Excel sont affublées d'un bug amusant: l'année 1900 est considérée comme bissextile, alors qu'elle ne l'est pas, ce qui induit un bug pour certaines fonctions. Alors, plutôt que gérer ça au chargement ou à la sauvegarde du fichier, les créateurs d'OOXML ont préféré l'inclure dans le format lui-même: les implémentations d'OOXML sont obligées de considérer l'année 1900 comme bissextile !
    Par ailleurs, il se trouve que la version Mac d'Excel prend 1904 comme base des années, au lieu de 1900 pour la version Windows. Alors, au lieu de gérer ça encore une fois au chargement ou à la sauvegarde, ça se retrouve dans le format: les implémentations sont obligées de gérer cette différence, pour être conforme au standard.
  • Une fonctionnalité plus ou moins inconnue de Word a été incorporée dans le standard de manière complètement débile. Il s'agit des "bordures de page artistiques". Oui, ça fait peur, n'est-ce pas ? Hé bien, Word en propose environ 200, dont je vous laisse seul juge de l'intérêt graphique. Et il se trouve que chacune de ces 200 bordures est explicitée dans le format. Sur plus de 40 pages. Chaque implémentation devra donc proposer ces quelques 200 bordures. Et c'est tout, car le format n'est pas extensible. Ainsi, plutôt que de fournir une structure extensible, par exemple en spécifiant une image liée au document, ce qui aurait allégé le format, on se retrouve avec 40 pages de description de bordures immondes.

Des champs de bits

Le tableau ne serait pas complet si je ne parlais pas des champs de bits inclus dans le langage. Pour ceux qui ne connaissent pas cette notion, je vais tenter d'expliciter un peu.

En informatique, tout le monde le sait, tout s'exprime sous forme de 0 et de 1. C'est ce qu'on appelle un bit. Par exemple, un caractère est représenté par 8 bits (ce n'est plus tout à fait vrai, mais passons), soit 256 caractères possibles. Et ces 8 bits, il se trouve que c'est la taille minimale stockable en mémoire, sur un disque dur, etc. C'est ce qu'on appelle un octet.

Mais si l'on veut juste représenter une vérité, vraie, ou fausse, nous n'avons besoin que d'un seul bit. Et le stocker sur 8 bits, ça semble quand même être une perte de place immense, surtout dans l'ancien temps, où nous n'avions pas tant de Go à ne pas savoir qu'en faire. Donc l'idée, c'est de stocker 8 vérités, 8 bits qui représentent chacun une vérité indépendante, sur un seul octet.

(Pffiou, jusque là, je m'en suis pas trop mal sorti, je pense.)

Ce genre de technique était utilisé très souvent (et doit l'être encore). C'est donc tout à fait normal d'en retrouver dans les structures internes des logiciels de la suite Office Microsoft.

Bon, et puis, j'avais écrit la suite, et je l'ai perdue suite à une fausse manoeuvre de ma part; je l'avoue, j'ai la flemme, alors pour les intéressés (et je ne doute pas qu'ils seront très nombreux), allez lire l'excellent article de Rob Weir (en anglais). Non mais.

Et pendant qu'on y est, voici la liste de tous ses billets sur le sujet; bonne lecture !