Office Open XML (également abrégé OOXML ou plus communément Open XML) est la désignation d’usage d’un standard de l’ECMA dont l’appellation officielle est « ECMA-376 : Office Open XML File Format » définissant un format de données pour les documents d’applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et formules mathématiques. Ce format est à l’instar du format ISO OpenDocument structuré en XML et Zip.
Originellement introduit par Microsoft, puis revu dans le cadre de sa standardisation par l’ECMA, ce format est structuré selon l’Open Packaging Convention qui définit un système de stockage des données flexible en utilisant une navigation logique à base de relations. La description sémantique des données se fait par l’ensemble des schémas XML normalisés.
Pour des raisons d’interopérabilité avec les anciens formats binaires d’Office, la partie réservée à la compatibilité de la spécification - partie entièrement optionnelle - mentionne néanmoins des éléments non-normalisés qui sont la propriété intellectuelle de Microsoft comme le WMF, la sauvegarde des données concernant le format d’impression et certains détails d’anciens logiciels édité par Microsoft. Dans ce cadre, Microsoft a publié un Covenant Not to Sue (ou CNS) s’engageant pour le futur à ne pas gêner les acteurs à utiliser le format, même si cela empiète sur la propriété intellectuelle de la firme. Une étude du cabinet d’expertise juridique anglais Baker & McKenzie, effectuée aux frais de Microsoft, décrit la validité et la portée juridique du contenu de ces documents en y engageant sa réputation. Dans la pratique, seule une jurisprudence pourrait donner une lecture certaine de ce document.
Ce format est présenté par l’auteur comme destiné à être utilisé par tous pour communiquer et aussi pour archiver les documents administratifs, culturels ou scientifiques et donc préserver une grande partie de notre patrimoine intellectuel ou historique, des enjeux techniques, économiques et de société.
Le format Office Open XML utilise une structure respectant l’Open Packaging Convention et définissant de façon simple et logique la structure interne de tous les documents Office Open XML. Selon cette convention, les documents sont des archives ZIP dont les différents éléments le constituant, appelés parties, sont reliées entre elles par des relations logiques. L’utilisation du ZIP permet outre de compresser les documents, de pouvoir stocker les données de façon totalement indépendante dans une architecture segmentée.
Cette architecture permet d’ailleurs de protéger les documents Office Open XML plus efficacement face à la corruption des données (si un élément est endommagé, les autres n’en seront pas affectés).
La notion de paquet définit l’archive ZIP en elle-même, c’est-à-dire le conteneur des données d’un document Office Open XML.
Une partie est un élément de l’archive ZIP, c’est-à-dire un fichier compressé et intégré dans la structure du ZIP. On distingue plusieurs types de parties : les parties de contenu et les parties de relations.
Les parties de contenu contiennent les données même du document, c’est-à-dire les informations qui définissent les données et la sémantique d’un document Office Open XML. Ces parties peuvent contenir du XML (par exemple le contenu d’un document de traitement de texte : paragraphes, runs, graphiques, …) ou des données binaires (par exemple des images GIF, JPEG, etc. ou des objets OLE).
Les parties de relations contiennent une structure XML définie dans les schémas de référence du standard ECMA-376.
Une partie spécifique et unique dans le paquet est celle des types de contenu décrite plus en détail dans une prochaine partie.
Les relations sont définies dans les parties de relations et spécifient les liens entre le paquet ou une partie source et une partie cible.
Une relation possède un type de relation spécifiant la nature de la partie pointée, et l’URI relative à la partie ciblée.
Les parties de relations possèdent un nom, représenté par une URI, qui doit respecter une convention de nommage particulière. Cette syntaxe stipulée dans le standard est le suivant :
Exemples :
Cette partie obligatoire porte un unique nom : [Content_Types].xml
Ce nom n’est pas compatible avec la syntaxe d’une URI : cela est un choix technique. Voici un exemple de contenu de la partie de types de contenu :
…
Cette définition de type définit deux types d’extension, celle par défaut qui spécifie que tous les éléments possédant l’extension stipulée sont du type défini, et celle qui surcharge l’extension définie par défaut en stipulant un type spécifique pour une partie spécifique.
Tous les types de contenu doivent être compatibles avec la RFC 2616 §3.7 (en tenant compte des règles du modèle d’empaquetage, le support des paramètres de type de contenu est proscrit).
L’objectif des parties de signature est d’assurer la sécurité des documents afin d’en garantir au moins l’intégrité et/où l’accès grâce à des certificats X.509.
Ces parties contiennent plusieurs informations qui sont détaillées dans une partie ultérieure.