Office Open XML

Les pays membres de l’ISO ont discuté et revu techniquement le standard ECMA-376 dans le but de s’assurer de la cohérence et de l’intérêt du contenu de la spécification.

Le 19 juillet 2007, le processus de normalisation ISO de OpenXML a subi un revers, le comité technique V1 ayant refusé l’état « approuvé avec commentaires » (qui signifie accepté), et aussi l’état « désapprouvé avec commentaires » (qui implique une demande de modification pour un probable accord ultérieur). Le comité technique en question était pourtant passé de sept participants au 1^er janvier à vingt-six participants, les nouveaux entrants ayant majoritairement voté en faveur de l’adoption[8].

Le 10 août 2007, le format Office Open XML fait l’objet d’un premier rejet à l’ISO : l’abstention de l’IEEE provoque la non-présentation du format à l’ISO[9].

Le 4 septembre 2007, le vote du comité ISO, planifié pour la potentielle nomination de ce standard au statut de normes ISO, est négatif (le vote ne recueille que 53 % de votes positifs, alors qu’il est nécessaire de réunir plus de 66 % de votes positifs et moins de 25 % de votes négatifs). Le représentant de la France à l’ISO (l’association française de normalisation Afnor), qui possède une voix lors de ce vote, choisit de voter « non avec commentaires ».

La possibilité de reconnaître OpenXML comme norme internationale est/a été contestée lors de la procédure de normalisation ISO 29500, à la suite d'une série d’éléments tant juridiques que techniques qui pourraient rendre malaisée l’implémentation d’OpenXML. À la suite de ces contestations, l’ECMA a formulé un document de réponse[10], destiné aux instances internationales, justifiant des choix techniques.

En plus des réponses apportées par l’ECMA, Microsoft a répondu à certains des points ambigus soulevés par les états dans un communiqué officiel[11].

Le statut de norme pour Office Open XML est jugé tendancieux par de nombreuses associations promouvant le logiciel Libre[12] - [13].

Des entreprises comme IBM[5] avancent que la norme est trop liée aux plates-formes du passé et désirent rompre avec cet état de fait. D'autres comme Google avancent que l'adoption d'un standard alternatif jouant le même rôle qu'un standard auparavant adopté (ODF) n'est pas bénéfique, et critiquent également la documentation qui est trop étendue pour être correctement revue : « ça prendrait 18 ans (6 576 jours pour 6 546 pages) pour aboutir à un niveau de revue comparable au standard ODF (871 jours pour 867 pages). »[14]

L’ODF Alliance, promotrice de l’OpenDocument, propose une feuille de faits qui dénonce la difficulté à transposer Office Open XML à d’autres suites bureautiques, la taille du document de la spécification, la redondance avec les standards actuels.

Il existe déjà une norme ISO 26300 pour décrire les documents de bureautique. La proposition de normalisation d’OpenXML contredirait les normes ISO 8601 (représentation des dates et des périodes), ISO 639 (codes pour la représentation des noms et des langues) ou ISO/CEI 10118-3 (fonctions de hachage en cryptographie)[15].

L'institut Fraunhofer de Berlin a réalisé une étude au sujet de l'interopérabilité entre ODF et OOXML. Le résultat est sans surprise : une incompatibilité entre les deux, imposant aux utilisateurs de soigneusement choisir l'un, sachant que leur choix les engage pour longtemps et qu'aucune conversion ne pourrait être parfaite[16].

Microsoft a distribué, en plus de l’existant Open Specification Promise un document promettant de ne pas poursuivre[17] les auteurs de l’utilisation de Office Open XML dans un autre logiciel que ceux de Microsoft. Cette promesse de non-poursuite elle-même laisse certains flous, notamment[18] :

• s’appliquant à la norme ECMA en l’état, s’applique-t-elle à une éventuelle version finale de l’ISO ?
• s’applique-t-elle à tous les brevets logiciels nécessaires à la mise en œuvre de la norme ?
• s’applique-t-elle également aux extensions du format OOXML ?

La licence d’utilisation de OpenXML est incompatible avec les programmes sous la licence GPL[19] - [20].

Certaines associations d’industrie ont même écrit à l’ECMA pour faire valoir qu'OpenXML était « non conforme aux conditions fondamentales de l’ouverture » (à l’époque)[21].

La possibilité et/ou facilité de transposition du format à d’autres suites bureautiques ou bibliothèques indépendantes de l’auteur original, a été remis en cause. Pourtant de nombreux produits implémentent le standard ECMA, en partenariat avec Microsoft (la version Novell de OpenOffice.org, NeoOffice, Corel WordPerfect, MindManager Mindmapping, Altova XMLSpy) ou non (Liste vide).

Plusieurs bibliothèques permettent aux développeurs/éditeurs de logiciels de créer des applications.

• Celle de Microsoft (espace de nom System.IO.Packaging pour .NET 3) est terminée.
• Une implémentation Libre pour la plate-forme Java sous licence BSD/Apache, OpenXML4J a été initiée par une entreprise française et reste actuellement en cours de développement.

L’ECMA a demandé l’examen de la proposition de norme OpenXML par l’ISO selon le mode rapide dit « fast track », mode qui demande que les éventuelles contestations soient formulées dans le délai d'un mois. Ce mode rapide est contesté par plusieurs organisations, en particulier au regard de la taille excessive de la proposition : plus de 6 000 pages, à comparer avec la taille habituelle (en moyenne 11 pages) des normes de l’ISO.

Malgré une majorité de votants contre l’adoption de cette procédure (14 négatifs, 5 neutres/mitigés et 1 pour), la procédure fut néanmoins acceptée par le bureau du TC1[22] en fonction des prérogatives dévolues au président.

Il est fait mention dans le document proposé de logiciels tel que « Word95 », or une norme ne peut citer de marque (élément alignAsWord95, autoSpaceLikeWord95, useWord97LineBreakRules)[15].

Un responsable de Microsoft a indiqué vers le milieu de 2008 que l’ODF a clairement remporté la victoire face à l’OOXML[23] - [24]. S’il convient de prendre ces propos avec précaution et de ne pas trop spéculer sur la stratégie future de la firme, cela semble néanmoins marquer la fin de la rivalité entre formats.

Cela semble aller dans la même direction que le support de l’ODF prévu par Office dans le prochain service pack (avec possibilité d’utiliser ODF par défaut).

Le 29 mars 2008, le vote d’adoption d’Office Open XML comme norme internationale DIS 29500 est positif[25], ce qui provoque une certaine polémique. L’Afnor, le représentant français, qui avait voté contre lors du premier vote, a décidé au dernier moment de s’abstenir. Alors que 80 % du comité norvégien voulait garder le « non » du premier vote, la Norvège se déclare finalement favorable à la normalisation de l’Office Open XML. La commission européenne décide d’ouvrir une enquête sur les conditions de ce vote[26].

Le 6 juin 2008, quatre membres de l’ISO, le Brésil, l’Inde, l’Afrique du Sud et le Venezuela, ont fait appel contre l’approbation des formats OOXML comme standards internationaux ISO/CEI[27].

Ces appels sont pris en considération par les secrétariats généraux de l’ISO et de la CEI, qui les ont soumis, avec commentaires, aux ISO Technical Management Board et IEC Standardization Management Board.

L'ISO et l'IEC (International Electrotechnical Commission) ont finalement rejeté le 17 aout 2008 les appels déposés et donné un feu vert définitif à la publication d'OOXML.

Cette décision a entrainé le fait historique d'une remise en cause affichée de la confiance portée à l'organisme de normalisation ISO de la part de six pays (Brésil, Afrique du Sud, Venezuela, Équateur, Cuba et Paraguay) dans un communiqué conjoint où l'on peut lire notamment :

« Il nous apparaît clairement maintenant que nous allons devoir, quoiqu'à contre-cœur, ré-évaluer notre appréciation de l'ISO/IEC, en particulier en ce qui concerne sa pertinence vis-à-vis des différentes structures d'interopérabilité de nos gouvernements nationaux[28]. »

En tout état de cause, l'ISO et la CEI ont successivement validé trois normes (dont la première, bien qu'elle n'ait jamais été mise en œuvre, a cependant conservé son statut de standard international) dans le domaine des formats de documents révisables, à savoir

• Open Document Architecture (ISO/CEI 8613) ;
• Open Document Format (ISO/CEI 26300) ;
• Office Open XML (ISO/CEI 29500).

Ces trois spécifications cohabitent sans que les organismes de normalisation aient pu, jusqu'à présent, établir clairement leur complémentarité, ce qui pose le problème de la cohérence et de la non-redondance de l'offre normative en vigueur dans ce domaine. Au-delà des qualités et des défauts techniques comparés de ces spécifications concurrentes, ce sont les objectifs et le mode de fonctionnement des organismes de normalisation qui suscitent désormais des réflexions critiques[29].

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.

 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
   <Relationship Id="rId3" Type="http://schemas.../metadata/core-properties" Target="docProps/core.xml" />
   <Relationship Id="rId2" Type="http://schemas.../metadata/thumbnail" Target="docProps/thumbnail.jpeg" />
   <Relationship Id="rId1" Type="http://schemas.../officeDocument" Target="word/document.xml" />
   <Relationship Id="rId4" Type="http://schemas.../extended-properties" Target="docProps/app.xml" /> 
 </Relationships>

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 indiquée dans le standard est la suivante : <chemin hiérarchique>/_rels/<nom de la partie source>.rels.

Exemples :

• la partie de relation du paquet n’a pas de partie source, puisque celle-ci est située à la racine même du document (et est obligatoire), sa syntaxe est unique : /_rels/.rels
• la partie de relations de la partie principale de contenu d’un document WordprocessingML possède l’URI suivante : '/word/document.xml', par conséquent la partie de relation associée (qui permettra par exemple, au contenu de cibler une image insérée dans le document) devra posséder l’URI suivante : /word/_rels/document.xml.rels

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 :

 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
 <Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
   <Override PartName="/ppt/slides/slide5.xml"
     ContentType="application/vnd.openxmlformats-officedocument.presentationml.slide+xml" />
   <Default Extension="png" ContentType="image/png" />
   <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml" /> 
   <Default Extension="xml" ContentType="application/xml" />
   …
 </Types>

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 indiquée sont du type défini, et celle qui surcharge l’extension définie par défaut en précisant un type spécifique pour une partie spécifique.

Tous les types de contenu doivent être compatibles avec la RFC 2616[30] §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.