Outil Client Riche

OpenDocument est un format ouvert de données pour les applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et base de données bureautique. OpenDocument est la désignation d'usage d'une norme dont l'appellation officielle est OASIS Open Document Format for Office Applications, également abrégée par le sigle ODF.

La spécification OpenDocument s'est très largement inspirée du format créé pour les premières versions de la suite bureautique libre et gratuite OpenOffice.org. Les deux formats sont en effet fondamentalement similaires, tant par leur structure générale que par la liste des objets documentaires qu'ils permettent de représenter.

Successeur du format initial d'OpenOffice.org, OpenDocument est avant tout proposé comme un format de convergence et d'interopérabilité entre logiciels bureautiques et, plus généralement, entre applications de traitement de documents. Il est compatible avec les normes de métadonnées du Dublin Core.

La mise en œuvre du format OpenOffice.org avait déjà été, en son temps, une innovation fondamentale, en ce sens qu'elle consacrait le principe d'un format bureautique formellement documenté et librement exploitable par des tiers. OpenDocument représente une extension de ce principe. En effet, non seulement il s'agit d'un format documenté, publié, librement exploitable, mais encore la spécification elle-même est sous le contrôle d'un organisme indépendant de tout éditeur de logiciel bureautique.

Un format ouvert et normalisé pour la bureautique

OpenDocument représente le premier effort de normalisation des formats de fichier de la bureautique, si l'on met de côté la spécification Open Document Architecture (élaborée à partir de 1985 mais jamais réellement mise en œuvre sur le marché), chaque application bureautique ayant auparavant son format propre non interopérable. Un format ouvert pour la bureautique fait partie intégrante d'une stratégie de fourniture logicielle. Tim Bray utilise toujours la même image dans ses présentations : il pose la question « Qui d'entre vous est sûr de posséder des documents auxquels il pourra accéder dans dix ans ? », puis « Qui d'entre vous est sûr d'utiliser la même application bureautique dans dix ans ? ». Comme il reçoit beaucoup de réponses affirmatives à la première question, et peu à la seconde, il continue en disant « Bien, donc je vais vous parler d'OpenDocument… »

OpenDocument trouve son origine dans le format XML utilisé pendant plusieurs années par Sun Microsystems pour les versions 1.x.x d'OpenOffice. À ce stade, ce format n'est pas plus ouvert qu'un autre. Lorsque David Faure, pour l'avancement du projet KOffice, annonce sa volonté de coopérer au sein de l'Organization for the Advancement of Structured Information Standards (OASIS), en vue d'en faire un format ouvert apte à être utilisé par toute application bureautique, il est rejoint par des "poids lourds" de l'édition de logiciels informatiques comme Adobe Systems, Corel, IBM et Google^[1]. Le comité ainsi constitué est renseigné sur les besoins des utilisateurs par de grands clients tels que Boeing, Intel, le National Archive of Australia, le New York State Office of the Attorney General ou la Society of Biblical Literature. Cet accord démontre une certaine lassitude, tant de la part des clients que des informaticiens, face aux formats fermés.

En mai 2005, la version 1.0 de la spécification d'OpenDocument est approuvée par le comité de normalisation de l'OASIS, et est disponible librement en téléchargement et est implémentable gratuitement par tous, comme le précisent les termes de la licence^[2].

Bien qu'OASIS ait changé sa politique^[3] pour autoriser les techniques sous brevets RAND dans ses normes, le groupe de travail OASIS OpenDocument, pour sa part, est resté à l'ancienne politique de licence, libre.

En septembre 2005, est déposée une demande en certification auprès de l'ISO (Organisation internationale de normalisation). Celle-ci a été attribuée le 1^er mai 2006. Le format OpenDocument est dorénavant une norme ISO26300:2006.

De nombreux logiciels utilisent la norme^[4], principalement OpenOffice.org, NeoOffice, StarOffice, KOffice. De nombreux éditeurs la soutiennent en l'utilisant (IBM, Novell et Sun). La demande grandissante d'interopérabilité dans les environnements bureautiques a conduit Microsoft à accepter, dans une certaine mesure, via un logiciel complémentaire de lire et d'enregistrer des fichiers au format OpenDocument dans certains composants de Microsoft Office (Word et Excel)^[5], la qualité n'est cependant pas forcément au rendez-vous ^[6].

En février 2007, OpenDocument 1.1, une nouvelle version de la norme, devient un standard Oasis, mais n'est pas encore un standard ISO.

Extensions de fichiers associées

Le format OpenDocument regroupe les formats suivants (avec les extensions de documents associées) :

Il existe également des modèles dans OpenDocument. Un modèle est constitué d'informations sur le formatage de documents (comme les styles) sans qu'il ne contienne lui-même les données.

Les modèles faisant partie de la norme sont :

Ces différents formats sont basés sur les formats ZIP et XML

Description du format

Contenu d'un fichier au format OASIS OpenDocument

Un format OpenDocument est une archive ZIP contenant un certain nombre de fichiers et de répertoires :

content.xml
meta.xml
settings.xml
styles.xml

mimetype
layout-cache

Basic/
META-INF/
Thumbnails/
Pictures/
Configurations2/

Le format OpenDocument soutient une forte séparation entre contenu, mise en page et méta-données.

content.xml

C'est le fichier le plus important, il contient le contenu réel du document (excepté le contenu binaire telles les images qui sont stockées dans des fichiers séparés). La syntaxe tire son inspiration du HTML et, quoique bien plus complexe, est raisonnablement compréhensible par un humain entraîné:

 <text:h text:style-name="Heading_2">Ceci est un titre</text:h>
 <text:p text:style-name="Text_body"/>
 <text:p text:style-name="Text_body">
    Ceci est un paragraphe. L'information de mise-en-page
    est stockée à part dans le style "Text_body" (Corps de texte).
    La balise vide text:p au-dessus correspond à un paragraphe
    vide, c'est-à-dire à un saut de ligne.
 </text:p>

OpenDocument a été conçu pour permettre la conversion de ces données depuis plusieurs formats propriétaires (de Corel, le .doc de Microsoft Office…). Il reconnaît donc les fonctionnalités habituelles des suites bureautiques : plusieurs niveaux de chapitres, listes, paragraphes numérotés, liens, Ruby, références, signets, historique des changements… On y trouve également les mécanismes pour générer automatiquement les tables des matières, les index et les bibliographies.

styles.xml

Un fichier OpenDocument est un ensemble d'objets décrits dans content.xml sur lesquels sont appliqués des styles définis dans le fichier styles.xml.

Un style est une collection de propriétés à la fois structurelles et de mise en forme. Une utilisation courante d'une application prenant en charge OpenDocument consiste donc à alterner entre la rédaction du texte et l'application de styles sur celui-ci.

Les styles s'appliquent sur toutes sortes d'objets: paragraphes, cadres, pages, caractères, numérotations, etc. Les propriétés qu'ils définissent sont entre autres : le type d'un texte (standard, titre, note de bas de page, etc.), les caractéristiques visuelles d'un texte (le choix de la police de caractères, la taille, l'alignement, la couleur, etc.), le type d'un compteur, l'ombrage d'une image, le nombre de colonnes d'une page, le sens d'écriture d'un cadre (par exemple, pour écrire du japonais à la verticale), etc. Les styles peuvent être créés pour toutes sortes d'usages et même avoir des propriétés conditionnelles. Pour les usages ponctuels de mise en forme, des styles automatiques, dépourvus de sens sémantiques, sont générés par le programme. L'abus de ces styles automatiques est considéré comme une erreur d'utilisation, surchargeant inutilement le document.

meta.xml

Ce fichier contient les métadonnées associées au document.

Une liste de champs prédéfinis fait partie du standard : application, titre, description, sujet, mots-clés, auteur initial, auteur, imprimé par, date de création, date de dernière modification, date de dernière impression, durée d'édition, modèle utilisé, rechargement automatique, comportement url (??), langue, nombre d'éditions, durée totale d'édition, statistiques sur le document.

Les métadonnées permettent de gérer l'interopérabilité entre divers types de ressources informatiques.

En anglais : Generator, Title, Description, Subject, Keywords, In.

Outils de développement

OpenDocument est conçu non seulement pour devenir un format commun pour les applications bureautiques du marché, mais aussi pour permettre la production ou l'exploitation automatique de documents dans le cadre de toutes sortes d'applications. L'objectif est de réaliser ces traitements en accédant directement aux fichiers, sans dépendre d'un logiciel bureautique quelconque, de manière à pouvoir développer des applications plus robustes, plus performantes et capables de s'exécuter dans d'autres environnements que les postes de travail des utilisateurs. Cet objectif concerne deux sortes d'applications, à savoir d'une part celles qui exploitent les données contenues dans les documents (traitement de formulaires, gestion électronique des documents), et d'autre part celles qui produisent ou modifient des documents à partir d'informations de gestion.

L'enjeu est important dans la mesure où il est de plus en plus nécessaire d'améliorer l'interopérabilité entre bureautique et système d'information.

L'outil le plus complet est UNO, mais il s'agit d'un cas très particulier. Plus qu'une simple interface de programmation, UNO est le composant central de la suite bureautique OpenOffice.org. De ce fait, il ne correspond pas tout à fait au critère d'indépendance envers un logiciel bureautique et implique des contraintes de performances non négligeables. De plus, du fait même de sa richesse, cet outil est d'un maniement complexe. Cependant, UNO permet aux programmeurs, si nécessaire, de disposer de nombreuses fonctionnalités automatisables d'OpenOffice.org et peut être utilisé dans plusieurs environnements. Il supporte nativement les langages Java, C++ et Python. Des adaptations pour d'autres langages (comme Perl, Delphi et Tcl) sont disponibles ou prévues, mais avec des possibilités plus limitées.

Pour développer des applications réellement indépendantes de tout « moteur » bureautique particulier dans de bonnes conditions de performances, on doit disposer d'outils offrant au minimum trois types de fonctionnalités :

• compression et décompression ZIP ;
• gestion de la correspondance entre le jeu de caractères local de l'utilisateur et le jeu de caractères UTF-8 dans lequel sont encodés les documents ;
• analyse syntaxique, production et recherche d'éléments dans des documents XML.

Ces fonctionnalités de base sont disponibles dans la plupart des langages de programmation usuels. Elles sont cependant peu productives et ne peuvent être utilisées que par des développeurs maîtrisant la spécification OpenDocument. Des outils de développement de plus haut niveau, plus spécialement conçus pour OpenDocument, sont nécessaires pour réduire la complexité des programmes et l'effort d'apprentissage du développeur. Dans ce domaine, plusieurs initiatives ont vu le jour ; certaines ont déjà produit des solutions opérationnelles, d'autres sont émergentes. En voici quelques-unes :

• LibOpenDocument est un projet d'interface de programmation d'usage général, initialement basé sur Python, initié par l'OpenDocument Fellowship.
• Open Document Format Utilities est une collection de classes Java, librement téléchargeables, destinée à extraire le texte ou les métadonnées d'un document.
• ODF Tools est principalement une collection de feuilles de styles XSL développées par l'OpenDocument Fellowship et destinées à convertir des fichiers OpenDocument dans d'autres formats et vice-versa.
• OpenDocument Connector alias OpenOffice::OODoc est une interface de programmation d'usage général, basée sur Perl et disponible en distribution CPAN (il en existe une présentation en Français[pdf]).
• OOBuilder est lui aussi un outil en Perl, également disponible en distribution CPAN, qui permet la création simple et rapide de documents.
• OpenDocumentPHP
• POD(Python Open Document) définit une manière très simple d'insérer des instructions spéciales (écrites en Python) dans un fichier OpenDocument Text (ODT) afin de produire des documents dont le contenu provient dynamiquement de n'importe quel programme écrit en Python. Il s'agit un peu du principe de l'HTML dynamique appliqué au format OpenDocument, si ce n'est qu'il ne requiert aucune connaissance du format OpenDocument : l'utilisateur de POD écrit ses documents directement dans son logiciel de traitement de texte (OpenOffice, KOffice, etc.).

Adoption

Dix-sept gouvernements nationaux et huit gouvernements régionaux ont adopté le format OpenDocument.^[7]

Administrations

OpenDocument est ciblé par certaines administrations désirant bâtir leur infrastructure publique sur des standards ouverts, pour des questions idéologiques et pratiques : liberté, transparence, concurrence^{[réf. nécessaire]}.

Logiciels

Suivant KOffice et OpenOffice.org, les créateurs de la norme, de nombreux éditeurs de logiciels expriment leur intérêt pour OpenDocument. IBM prône l'utilisation unique du format OpenDocument dans l'ensemble de ses produits de la gamme Notes et Workplace.

Le 3 mars 2006 naît une Open Document Alliance.

OpenDocument est aussi le format par défaut utilisé par Google Document [1] et par Lotus Symphony d'IBM [2].

Mac OS X v10.5 inclut une nouvelle version de TextEdit qui permet d'enregistrer et importer des documents OpenDocument.

Le SP2 d'Office 2007 supporte l'ODF, ainsi que le format PDF, nativement^[8].

État du Massachusetts

OpenDocument est médiatisé en 2005 par une démarche de l'État américain du Massachusetts décidé à développer le projet précurseur d'une infrastructure publique basée sur des standards ouverts, interopérables, concurrentiels et pérennes, en opposition à la situation antérieure où elle dépend uniquement des applications utilisées.

Une partie essentielle de cette démarche consiste en l'évaluation et la sélection de formats de fichiers pour le domaine de la bureautique. Après une évaluation des différents candidats étalée sur huit mois et soumis à un intense lobbying de la part de toutes les parties, il est statué le 21 septembre 2005 :

1. que « pour assurer le maximum d'interopérabilité, il est recommandé que les extensions propriétaires à tout format XML soient évitées. »^[9] La politique de licence trop restrictive conduit à rejeter le format Open XML de Microsoft Office. OpenXML ne serait pas compatible avec les programmes sous licence GPL^[10] ;
2. de standardiser les formats texte : HTML, PDF^[11] (mise en page parfaitement conservée) ou OpenDocument (documents éditables) ;
3. que la migration vers le format OpenDocument doit se faire d'ici le 1^er janvier 2007^[12].

Le titre aguicheur sous lequel cette décision a été présentée par de nombreux journalistes, « L'État du Massachusetts exclut Microsoft Office de son infrastructure », est inexact car la décision porte uniquement sur le format des données ; Microsoft reste libre d'implémenter le format OpenDocument. Mais Alan Yates a adressé, au nom de Microsoft, une longue réponse[pdf] à Eric Kriss et Peter Quinn, hauts représentants de l'État du Massachusetts, expliquant que la société Microsoft n'entend pas prendre en compte le standard OpenDocument, s'excluant elle-même de ce marché public. Les concurrents de Microsoft ont sévèrement critiqué ce refus et l'argumentation qui l'accompagne^[13]. Selon eux, Microsoft refuserait d'avoir à affronter une concurrence basée sur les seuls mérites des applications respectives : fonctionnalités, rapidité, ergonomie, prix.

Après le départ de l’ancien responsable des opérations informatiques^[14], l’État du Massachusetts n’adopte plus une position aussi tranchée, le doute s’immisçant quant à la motivation et à l’objectivité des défenseurs de la solution libre.

Le gouvernement de l’État se félicite, quant à lui, de « l’attitude d'apaisement de Microsoft, notamment suite à son annonce d’ouvrir son standard XML dans le cadre de la prochaine suite Office 12. » Cela signifie en termes à peine voilés l’abandon de la stratégie d’Eric Kriss.

Union européenne

L'Union européenne a évalué différents formats bureautiques et s'est prononcée favorablement sur OpenDocument comme base d'un format standard pour l'échange de documents. La Commission européenne écrit notamment dans sa lettre finale d'évaluation d'OpenDocument : « Les nécessités de transparence et d'accessibilité dictent que les échanges d'informations publiques avec les gouvernements évitent de dépendre de technologies qui impliquent ou imposent un produit ou une plate-forme en particulier pour les affaires ou les citoyens. »

Dans cette évaluation, la Commission européenne a demandé également que le format OpenDocument soit présenté au comité de normalisation ISO. Sun Microsystems et le comité OASIS ont accepté.

En avril 2006, l'utilisation du format OpenDocument est recommandée par la DGME qui lance un appel public à commentaires sur la base d'une version du projet de Référentiel Général d'Interopérabilité^[15].

En mai 2006, l'ISO/IEC a adopté le format, qui est devenu ainsi la norme ISO/IEC 26300:2006. Cette dénomination ayant été obtenue, l'Union européenne ou ses membres pourraient à présent recommander ou même imposer OpenDocument.

Vendredi 2 juin 2006, le Danemark a franchi une étape importante en Europe en votant à l'unanimité un projet visant à utiliser les standards ouverts – ODF en particulier – dans tout ce qui touche aux technologies de l'information dans le pays.

Vendredi 23 juin 2006, le Gouvernement fédéral belge décide de rendre obligatoire dans son administration le format Open Document à partir de septembre 2008^[16],[17]. La Belgique est le premier État au monde qui interdit de facto l'usage de formats propriétaires tels que ceux de Microsoft^[18]. En septembre 2007, le format devrait être lisible par toutes les administrations du pays^{[citation nécessaire]}. En septembre 2008, ODF devrait être obligatoire comme format de fichier d'échange entre les différents services et administrations belges.

En France, le député Bernard Carayon recommande également l'utilisation d'OpenDocument dans son deuxième rapport sur l'intelligence économique et la normalisation, intitulé À armes égales^[19].

De plus, la Gendarmerie^[20] et l'Assemblée Nationale^[21] françaises ont également adopté une politique très ouverte en matière de logiciels libres.

Cependant l'AFNOR a rejeté, en septembre 2007, la transposition d'OpenDocument en norme française. La seule norme française officiellement en vigueur demeure ODA, qui n'a jamais été réellement mise en application. La normalisation institutionnelle reste donc, en France, largement attentiste et ne semble pas pouvoir actuellement servir de guide dans le domaine des formats de documents révisables.

Limitations

Des critiques variées ont été soulevées à propos de cette norme approuvée — la version 1.0 de OpenDocument.

• Des mathématiciens^{[réf. nécessaire]} estiment que le choix de la norme MathML du W3C pour une utilisation dans le format OpenDocument est un choix discutable. MathML est une recommandation du W3C, qui existe depuis 1999^[22] pour l'inclusion d'expressions mathématiques dans des pages web et la communication entre machines. Néanmoins, la plupart des mathématiciens continuent d'utiliser le — bien plus ancien et non moins efficace — format TeX en tant que première méthode pour transcrire des formules mathématiques complexes. TeX n'est pas une norme ISO mais un standard de facto pour retranscrire des expressions mathématiques. On critique aussi OpenDocument pour ne pas utiliser la norme ISO 12083:1994 pour la transcription d'expressions mathématiques — MathML ne l'utilise d'ailleurs pas non plus. MathML possède quelques problèmes^{[réf. nécessaire]} pour représenter des expressions complexes de manière correcte ; cela n'est pas le cas d'autres méthodes telles que TeX.
• La spécification de OpenDocument ne définit aucun langage de formules. Ceci fait en sorte que les fichiers conformes à la norme ISO n'ont pas à être compatibles^[23]. Le groupe de travail OASIS travaille à la création d'un langage de formules standard — OpenFormula — à intégrer dans OpenDocument 1.2.
• La spécification OpenDocument ne permet pas l'utilisation de tableaux dans les présentations. Ce problème est en traitement pour les prochaines versions de la spécification OpenDocument, mais n'était pas inclus dans la version soumise à l'approbation par l'ISO^[24]. La recommandation courante, un tour de passe-passe, est d'inclure une feuille de calcul dans la présentation pour accéder aux fonctionnalités désirées.
• Les différents logiciels qui exploitent ODF comme format de fichiers par défaut ont différentes méthodes de gestion des macro-commandes et des scripts. Il n'y a aucun langage de macro-commande spécifié dans ODF. Définir un langage de macro à utiliser est en soi un sujet de débat^[25].
• Les applets Java sont décrites comme des objets natifs dans la spécification OpenDocument (§9.3.4). Cela signifie que toutes les implémentations complètes vont nécessiter la présence d'une machine virtuelle Java dans le logiciel gérant l'ODF. Toutefois la conformité à la norme ne nécessite pas une implémentation complète de la machine virtuelle.
• La norme ODF n'est pas assez détaillée ; elle nécessite un recours excessif à des extensions spécifiques à un logiciel pour l'enregistrement de fonctions spécifiques dans les documents. Ces extensions spécifiques ne sont pas nécessairement inter-opérables entre les logiciels gérant l'ODF^[26].
• Le Sun OpenDocument Patent Statement s'applique aux futures versions d'ODF seulement si Sun prend part au développement de ces versions. Si Sun n'y participe pas, l'absence de poursuite quant à l'utilisation de ses brevets étasuniens ou internationaux par un tiers n'est plus garantie^[27].
• Même si OpenOffice.org permet de signer numériquement un document et sauvegarde le tout dans les fichiers ODF conformément à XML-DSig, les versions 1.0 et 1.1 de OpenDocument ne font pas référence à un système de signature numérique. Cela ne fait pas partie de la spécification de la norme OpenDocument ; cela correspond à une fonction spécifique au seul logiciel OpenOffice.org et n'est pas une fonction présente dans d'autres logiciels gérant l'ODF, comme la suite KOffice. Néanmoins ODF 1.2 inclura XML-DSig de la même façon que le fait actuellement OpenOffice.org. Les signatures numériques de l'ODF seront compatibles avec KOffice 2.0^[28].

Voir aussi

Notes et références

Articles connexes

• Comparaison d'applications supportant OpenDocument
• Format de données
• Format ouvert
• Interopérabilité informatique
• KOffice
• Lotus Symphony
• MathML
• Métadonnée
• OpenOffice.org
• Référentiel général d'interopérabilité
• XML

Liens externes

• (en) Catégorie OpenDocument de l’annuaire dmoz
• (en) L'ODF Alliance
• (fr) Bureautique : le format Opendocument sur Apitux.org
• (fr) Du nouveau autour du format OpenDocument
• [pdf] (en) Le standard OASIS pour OpenDocument (ODF)

• Portail de l’informatique
• Portail des logiciels libres