L’API pour Open XML est sortie il y a quelques semaines déjà, néanmoins voici quelques détails et liens pouvant vous apporter quelques lumières sur ce fameux SDK dont certaines personnes (n’est-ce pas Alexandre ?) semblent éprouver quelques difficultés à se servir ou à comprendre sa portée réelle.
Pour rappel, l’assembly WindowsBase.dll apporté par .NET 3.0 fournissait l’espace de nom System.IO.Packaging. Si vous avez .NET 3.0 (Vista ou Windows Server 2008) ou 3.5 d’installé, vous devriez pouvoir l’utiliser sans aucun problème dans vos applications. Le SDK Open XML sorti bien plus tard (lien de téléchargement ici), est une assembly DocumentFormat.OpenXml autonome qui fournit l’espace de nom DocumentFormat.OpenXml.Packaging. Le fait que cette assembly soit autonome vous permet et de la redistribuer avec vos applications (utilisant au moins le framework .NET 3.0) sans avoir à mettre à jour le framework de la machine vers le 3.5 qui est horriblement long à installer (et je ne parle pas du SP1 …).
Migrer de la CTP vers la RTM
Pour ceux qui aurait encore la version CTP d’installer sur leur machine de développement et qui souhaiteraient passer à la version finale, la première chose à faire pour migrer vos projet est de référencer la nouvelle Assembly DocumentFormat.OpenXML.dll. Remplacez tous vos using Microsoft.Office.DocumentFormat.OpenXml.Packaging; par using DocumentFormat.OpenXml.Packaging;. Et oui Microsoft à retiré son nom et ‘Office’ devant l’espace de nom final !
Un SDK, oui mais pour quoi faire en fait ? Ca change quelque chose ?
Notez que les deux espaces de noms n’offrent de fonctionnalités que pour manipuler l’enveloppe Open Packaging Convention - la structure interne du document – et non le XML des parties : vous devez toujours utiliser les API XML pour vous débrouiller avec la structure XML des parties (et lire les spécifications). Pour résumer, vous n’avez pas – encore, en attendant la V2 du SDK – de méthodes vous permettant de réaliser des tâches du genre : ajouter un paragraphe, insérer une image, spécifier la valeur d’une cellule, etc.
Pour les personnes désirant un peu de documentation sur le SDK Open XML, c’est par ici : http://msdn.microsoft.com/en-us/library/bb448854.aspx. Pour ceux qui veulent des articles d’introduction, voici deux bons articles sur le sujet (créé avec la CTP : Partie 1 et Partie 2 – pensez à changer les espaces de noms utilisés) de Franck Rice, et en Français en plus ! Notez également dans vos flux, les blogs de Eric White (évangéliste Open XML MS Corp) et de Doug Mahugh (ancien évangéliste Open XML et maintenant des standards dans Office).
Voilà pour la petite piqure de rappel !
Vous générez des documents Open XML, Office ne veut pas les ouvrir ? Voici quelques moyens d’en découdre avec un Office qui n’est pas bavard sur les erreurs …
Voici les causes d’erreur les plus probables et leur solution :
- Content Type : source principale des erreurs de ‘corruption’ de documents Open XML => A vérifier en premier, on oublie toujours le content type d’une partie que l’on rajoute (l’API de System.IO.Packaging le fait pour vous). Dézipper tout votre document et vérifier que chaque partie possède bien une entrée de Content Type en adéquation avec votre contenu,
- Relations : les relations associent les parties entres elles et permet d’avoir une cohésion des données dans un document. Si une des parties n’est pas référencé, Office ne saura pas la retrouver (quelques cas exceptionnel pour les parties principales avec la bonne convention de nommage mais Office râlera quand même à l’ouverture. Attention aux relations implicites également (il en existe quelques unes, par exemple avec les parties de Custom XML),
- XML des parties mal formé ou invalide : vérifiez évidemment que vos structures XML soient bien formées (la grammaire XML est respectée : 1 balise ouvrante pour une balise fermante, respect des prototypes - & > etc –, etc) et valide au schéma de la partie (respect du schéma XSD référencé en début de structure XML avec les espaces de noms)
Le
SDK Open XML possède une méthode de validation de document (uniquement pour les parties et les relations, pas encore pour le contenu XML) et
PackageExplorer possède un vérificateur (qui cette fois-ci valide également le XML de vos parties).
Utilisation de lastRenderedPageBreak
Pour ceux qui ne connaissent pas cet élément permettant d’informer votre logiciel de traitement de texte de la césure du rendu d’une page, le voici pour vous :
2.3.3.13 lastRenderedPageBreak (Position of Last Calculated Page Break)
This element specifies that this position delimited the end of a page when this document was last saved by an
application which paginates its content.
[Guidance: This element shall be used by applications to specify the locations of page breaks within a document
when it is saved as WordprocessingML, in order to allow other applications (e.g. assistive software) to utilize this
information when reading the document. end guidance]
[Example: Consider a run which consists of the text This is the end of the page, where the word end
was the last word on a page. If the application saving this file had paginated this content, that information may
be saved with the file as follows:
<w:r>
<w:t>This is the end</w:t>
<w:lastRenderedPageBreak/>
<w:t xml:space="preserve"> of the page</w:t>
</w:r>
The lastRenderedPageBreak element indicates that there was a page break resulting from pagination of this
content, which occurred between the word end and the word of. end example]
Utilisez cet élément à bon escient (mais utilisez-le car les routines automatiques exploitant les documents Open XML en sont friands pour découper un document au bon endroit … exemple transformation en HTML/PDF ou XPS) mais sachez les mettre au bon endroit. Pourquoi cet élément est aussi important car il permet dans une moindre mesure de pouvoir préparer vos documents à des logiciels d’accessibilité aux personnes handicapées. Si vous ne savez pas calculer leur emplacement, omettez-les tout simplement. Cela peut conduire selon l’implémentation de Open XML à des déformations de texte, voir à un saut de page non voulu (attention cet élément n’est pas le saut de page “PageBreak” ! C’est un élément non visuel, d’information uniquement). On ne sait pas ce qu’une implémentation désirant être absolument conforme à une autre, est capable de faire avec ce genre d’éléments.
Téléchargez le projet sur le site officiel et installez le :
Ouvrez le ruban pptPlex :
Choisissez un magnifique fond et insérez des sections dans votre présentation :
Et utilisez le en lançant la présentation depuis le ruban pptPlex :
Addin vraiment bien réalisé mais attention aux présentations lourdes (beaucoup de slides, plein d’image, de formes et d’animations) … les lenteurs arrivent vite, très vite !
Impact dans le document Open XML
On pourrait se demander comment Microsoft a réussi à stocker des données supplémentaire dans le document Open XML. Et si vous vous le demandez, voici quelques unes des modification dans le document nécessaires pour intégrer pptPlex :
Ajout type de contenu de tag :
<Override PartName="/ppt/tags/tagN.xml" ContentType="application/vnd.openxmlformats-officedocument.presentationml.tags+xml"/>
Ajout de partie de tag dans /ppt/tags avec un contenu similaire :
<p:tag name="PLEXMETADATA" val="<?xml version="1.0" encoding="utf-16"?>
<Metadata xmlns:xsi=&q …
Et quelques autres éléments du document qui s’adaptent. Comme quoi on peut toujours innover dans une application et même si la prouesse de stockage relève plus du bidouillage (embarquement de la structure XML encodé dans un attribut ! Mais difficile au moment d'un test de faire autrement il faut le reconnaître), le résultat est plutôt sympathique pour naviguer dans une présentation PowerPoint.
Conclusion
Un addin intéressant qui ne semble pas indispensable pour le moment (quelques fonctionnalités/usages à prendre dans iWorks avant celle-ci) car il y a toujours d’autres fonctionnalités qui manque et notamment celle des transitions 3D (je sais je me répète depuis 2005 sur ce sujet - OOo 2.4 le fait déjà sur Linux) !!! En standard avec Office 14 ?
Ce post n’a pas voulu partir ni jeudi ni vendredi, le voici donc !
Des mise à jours à n’en plus finir !
Hésitant à ne faire qu'un relai d’information sortant tout droit du autre post, ici de Doug Mahugh (j’avoue avoir loupé moi-même les annonces de ces produits), voici quand même l'ifnormation du lot de mises à jour autour des outils Open XML et de ODF :
Open XML/ODF Translator Version 2.0. Version 2 of the ODF translator project has been released. It includes significant performance improvements for spreadsheets, as well as numerous new features for all three document types and various bug fixes and enhancements based on feedback from users of Version 1. See the ODF translator team blog for all the details.
Docx4j version 2.0. Speaking of versions 2.0, a new release of docx4j is now available. This is a Java developer tool that creates an in-memory representation of a WordprocessingML document. See the use cases for examples of typical uses of docx4j.
OpenXMLDiff vNxt. Pranav Wagh said a while back that he'd start contributing to the OpenXMLDiff project, and he has already made a big difference. See his blog post last month for details (including a nice GUI interface to the core DLL), and there's an even newer build available now on the OpenXMLDiff project page.
ODF 1.0 errata released for public comment. The OASIS ODF TC has released an ODF 1.0 errata for public feedback. Jesper-on-the-spot posted it before I even saw the announcement on the OASIS list, and has a few interesting observations and comments. If you want to provide feedback, you'll need to do so by August 22.
Open XML Power Tools / Workflow Foundation
L’équipe Staff Dotnet continue ses posts sur PowerTools avec un post concernant l’utilisation dans un workflow WF.
Voici ceux de Eric White sur le même sujet :
Utilisation de Linq To XML avec Open XML
Voici les liens MSDN ou d’Eric White (évangéliste MS Corp pour XML/Open XML) qui devrait compléter les votre sur l’utilisation de Linq To XML avec Open XML:
C’est officiel, les appels de l’Afrique du Sud (Christian on va toujours là bas pour la coupe du monde ?), du Brésil, de l’Inde et du Vénézuela contre DIS 29500 aka Open XML ont été rejetés par l’ISO.
Voici les résultats de l’ISO reçu par les membres de l’AFNOR dans leur messagerie :
| MB members | Yes | No |
| ABNT (Brazil) | X | |
| AENOR (Spain) | | X |
| AFNOR (France) | | X with comments |
| ANSI (USA) | | X |
| BSI (United Kingdom) | X with comments | |
| DIN (Germany) | | X |
| JISC (Japan) | | X |
| NEN (Netherlands) | X with comments | |
| SABS (South Africa) | X | |
| SAC (China) | X | |
| SCC (Canada) | X | |
| SN (Norway) | | X with comments |
| Total | 6 (50%) | 6 (50 %) |
La majorité des 2/3 (66,66%) n’a pas été atteinte, ce qui constitue un rejet de la prise en compte des appels contre la procédure de normalisation de Open XML qui bloquait son évolution à l'ISO afin d'être une norme publiée (est-ce encore une ruse des partisans de l'ODF ?).
Plus qu’aux journaux web de véhiculer la nouvelle, et le statut de IS29500 va pouvoir avancer à l’ISO, enfin !
Mise à jour 18/08/08 : Voici le lien officiel de l’ISO de cette annonce : http://www.iso.org/iso/pressrelease.htm?refid=Ref1151
Un rappport de l’Université de l’Illinois concernant l’interopérabilité entre les implémentations de Open XML et de OpenDocument a été rendu public fin de semaine dernière. Ce rapport de Jay Kesan et Rajiv Shah présente un tour d’horizon des produits (propriétaire ou Libre) du marché. L’introduction de ce rapport introduit bien le problème :
The belief is that by shifting to open standards, governments will benefit from choice, competition, and the ability to seamlessly substitute different vendor implementations. … While it is widely acknowledged that there are problems with interoperability across different formats, e.g., going from ODF to OOXML, there is an assumption here that all implementations produce the same ODF or OOXML.
Voici les résultats pour les implémentations Open XML :
| Implementation | Score brut | Pourcentage score brut | Pourcentage pondéré |
| Office 2007 | 148 | 100% | 100% |
| Office 2003 | 148 | 100% | 100% |
| Office 2008 (Mac) | 147 | 99% | 99% |
| OpenOffice | 141 | 95% | 96% |
| Pages | 142 | 96% | 95% |
| WordPerfect | 114 | 77% | 84% |
| ThinkFree Office | 101 | 68% | 83% |
| TextEdit | 52 | 35% | 43% |
Voici le résultat pour les implémentations ODF :
| Implementation | Raw score | Raw score Percentage | Weighted Percent |
| OpenOffice | 151 | 100% | 100% |
| StarOffice | 149 | 99% | 97% |
| Sun plug-in for Word | 142 | 94% | 96% |
| Plugin CleverAge pour WOrd | 139 | 92% | 94% |
| WordPerfect | 122 | 81% | 86% |
| KOffice | 121 | 80% | 79% |
| Google Docs | 117 | 77% | 76% |
| TextEdit | 55 | 36% | 47% |
| AbiWord | 48 | 32% | 55% |
Comme vous pouvez le constater, les implémentations sont loin d'être égale entre elles.
Quelques conclusions des auteurs :
There are several significant implications that flow from these tests. They include the lack of 100% compatibility between implementations, the lack of good implementations outside of Windows, and the overall performance of OOXML implementations.
The final implication stems from the surprisingly good results for OOXML implementations. Critics of OOXML have argued that it was too complex and difficult to implement. While OOXML is a long and complex standard, it is possible to offer good compatibility. In fact, our results suggest that implementations of OOXML work as well as implementations of ODF.
Il y a beaucoup d’autres commentaires (comme la vitesse d’exécution des implémentations, le nombre de celles-ci sur les plateformes, etc) et les auteurs font part de certaines limitations dans leurs tests (par exemple, limité aux documents de traitement de texte). Néanmoins il est clair que nous pouvons conclure :
- Le standard Open XML plus long que son concurrent ne rend pas beaucoup plus difficile son implémentation, ni ne limite l’interopérabilité des implémentations,
- Il y a encore du travail pour obtenir une excellent interopérabilité entre les implémentations (nécessite d’un jeu de tests commun ?),
Et pour finir, je dirais que ce n’est pas parce que vous choisirez un format ouvert que vous aurez une bonne interopérabilité et que vous ne serez plus dépendant d’une implémentation/d’un produit. Au vu des liens sur le côté droit de la page web du rapport, je dirais que ce rapport n’a pas été fait dans l’intention de promouvoir Open XML, ce qui n’est que plus flatteur.
Lien de téléchargement du rapport.
PS : A quand un test avec le SP2 – pre alpha - de Office 2007 ?
Microsoft a récemment annoncé son ambition d’apporter un support natif du format OpenDocument directement dans Office 2007 via le prochain Service Pack 2. Doug Mahugh vient de donner quelques précisions sur comment cela sera inséré dans Office 2007. Rappelons que c’est la version 1.1 qui sera implémentée puisque c’est la version la plus récente de ODF approuvé par l’ISO (nous sommes toujours dans l’attente de la finalisation de la 1.2 à l’OASIS).
Pour ne pas tout raconter sur les différents challenges que l’équipe de développement devra surmonter (et il y en a croyez moi !), et parce que Doug le fait bien mieux que moi, voici juste la ligne directrice du développement de cette implémentation de ODF :
- Adhere to the ODF 1.1 Standard
- Be Predictable
- Preserve User Intent
- Preserve Editability
- Preserve Visual Fidelity
Des leitmotivs qui devraient avoir raison des utilisateurs les plus récalcitrants puisqu’ils sont clairement orientés vers lui. En attendant de pouvoir tester une première version de ce SDK, voici la représentation partielle de l’intégration de l’implémentation ODF dans Office 2007 : au même niveau que Open XML et autres formats binaires !
Promi dés qu’une version me tombe sous la main (comme ça par inadvertance, non non ce n’est pas une demande cachée), je vous en ferais un retour.
Aucune date officielle n’a pu encore être donnée pour la sortie du SP2 d’Office 2007 mais cela devrait sûrement survenir vers mi 2009 (en même temps que la sortie du SDK Open XMl et Office 14 ?). Egalement la Beta de OpenOffice 3 vient d’être rendu publique – ici - et comme vous le savez, cette version 3 contient un embryon de support (import seulement) Open XML et un premier support du prochain ODF 1.2. A tester donc si vous en l’opportunité.
Interopérabilité : le temps au beau fixe entre Microsoft et OpenDocument
Il y a quelques jours se tenait un workshop organisé par Microsoft sur le campus de ce dernier pour parler de l’implémentation de ODF dans Office 2007 (évidemment il m’était difficile de pouvoir y participer, et pourtant ce n’était pas l’envie qui manquait). Quelques Microsoftees l’avaient annoncé sur leur blog et quelques personnes présentes (qui ne sont pas spécialement des pro Microsoft) ont fait des comptes rendus sur leur blog et qui montre deux choses : la compétence et la passion des Microsoftees et la réelle sincérité pour Microsoft de s’insérer dans le monde des standards et de ODF :
What’s make ODF so much famous these last months ? Obviously the war against the “Microsoft – not anymore – Office Open XML file format”. For those thinking that OpenXML is just bad and never try to read the specs, and more importantly to use or implement it : did you wonder why Microsoft elaborate such a document file format ? No ? You just think that’s because Microsoft still want to dominate the world and use it again its fair monopole in the office market to make more money ? You wanted so much ODF that now you’ll have ODF in Office (and for a lot of activists, I’m sure you won’t even try to use a single copy of Office 2007/14 even with the ODF support, what a shame). You think this is for the best, that you save the humankind against the Microsoft tyranny ? And maybe you think that you can be a local hero by saving your country to buy Office licenses ? (obviously it’s a crap) However, do you really know the ODF file format, I mean more that : it’s ‘open’, it’s free (Free ?) and it’s zip and XML ?
An Illusion or Mirage
If you are one of those who think about a document format – like ODF, Open XML, etc - by thinking of only wordprocessing documents (this is usually the first and only picture that raise in people’s mind when thinking about Open XML), you are a victim of the great illusion. And you also make the assumption that you can describe three fully feature file formats in less than 700 pages with only a superficial description of the XML schema. I know it’s beautiful to think this way, but it’s too beautiful to be real.
This is the ‘ODF real illusion’ (I especially recommend you Inevitable Illusion by Massimo Piatelli to better understand this point) because, if you’re really thinking this way, you just never implement an office file format, or you already have strong knowledge in this area, or the format is simple AND quite poor. Why the ‘and’ in the last assumption, because advanced feature are always – more than 95% – complex to describe in a file format : do you naturally know how to specify a master in a presentation file format (with a 3 level style inheritance : from the master, the slide layout and the shape style) ? How to describe a dynamic crossed table or a 3-D chart in a spreadsheet ? How to set a cell value and know the impact of the modification in the formula calculation cycle based on the specifications ? If you still think that less than 700 pages are sufficient in regard to the complexity of the three office file format description (wordprocessing, spreadsheet and presentation) and inside mechanisms, either you’re dreaming or you are a genuine genius.
Technically it appears that the so 'open' ODF is a good competitor for the next generation file format war (the upcoming “e-document era”) however the functional aspects that normally make ODF a good format for companies and gouvernments is just a mirage that the ODF propaganda don’t stop to spread. Why ? Just keep reading. Don’t mislead, I also love this format.
OpenOffice forever or not
If you just need to add some paragraphs with simple style in a
document, fine, you don’t even have the need to read the specs ! Just
open OOo Writer, write some stuff, save it and unzip the final document
to retrieve the content.xml file and finally open it in your favorite XML
software. You will be able to understand quickly how to generate more
paragraphs without even reading one page of the specs. This method is
called reverse engineering and is not a best practise nor a guarantee
to use the standard itself ; unfortunately this is the method use by a
large majority of developers to implement a standard and especially ODF
(Open XML, PDF, etc have the same fate).
As a user of the first version of the OpenOffice.org (yes the very buggy v1.0 … I apologize to my friends to have forced you to use this great but completely unusable version), just because I didn’t like the way of using Microsoft Office XP/2003 daily as a word processor software. Nevertheless think two or three times before adopting this so hype OpenOffice. The format is technically simple (but who cares about this point except a few developers) with a great popularity rating but be aware of :
- You have a complete Microsoft documents corpus : you can’t translate your document without losses (if you have print oriented document … too bad),
- You want to add metada : you can’t, hopefully the version 1.2 will bring this possibility,
- You need accessibility features (gouvernment are the primary target) : wait for the next release,
- You want to digitally sign your document : this feature will be implemented as part of ODF 1.2 (granularity of this feature ? For example, Open XML allow to sign only a subset of the parts : to sign only the content parts but not the style parts – header, footer, style, etc),
- You use the dynamic crossed table in Excel : NOT supported in ODF even the latest version. You need this powerful analysis feature, you definitely won’t have it,
- You want to create or translate Formula : only the latest ODF version – the upcoming 1.2 - defines something but you won’t have a perfect cross format interoperability,
- You need the databinding feature (aka Custom XML) of Open XML : you WON’T have it with ODF,
- You have working Excel documents with complex macros : you have to learn and rebuild ALL your macros,
- You use SharePoint and other products build on top of Office : you know the answer !
As a developer, you know XML, XML Schema, XPath, XSLT, etc but do you know RNG (Relax NG), the OASIS’s XML validation language ? Until the release of ODF, I wasn’t even aware of it ! OASIS standardized ODF and RelaxNG, so don’t ask why the ODF file format is specified in RelaxNG instead of the commonly use XML Schema. RelaxNG is more advanced compare to XML Schema, fine but if you don’t have – or few - developers and tools to work with, it’s more difficult. Did ODF represent a chance for OASIS to force people to use their own XML description language ?
This post could be 1 kilometer long so I’ll stop the craps now and simply announce my new post series named ‘stop the craps about ODF and Open XML, and see what’s really inside !’. So stay tune if you want to know how and when to use either ODF or Open XML !
Vous connaissez tous XML et JSON (le format d’échange javascript) pour les formats d’échange de données sur Internet. Non content de ceux déjà existants, mais surtout pour des besoins sur mesure, Google nous en introduit aujourd’hui un nouveau : Protocol Buffers. Après quelques heures de tests en utilisant la version Java, voici donc quelques retours sur son utilisation.
Tout d’abord pourquoi un nouveau protocole d’échange alors qu’ils en existent déjà pléthore ? Tout le monde utilise en général les Web Service/REST avec XML/JSON pour communiquer entre système, cependant :
- SOAP est un protocole plutôt lourd, il faut créer ou remonter complètement la pile du protocole ce qui a tendance à être assez lourd pour le serveur,
- XML est verbeux et assez lourd pour passer sur un réseau,
- XML est souvent long à parser, surtout en cas de schémas XML multiples et de structure complexe,
- le XML n’est pas adapté pour échanger des objets sur un réseau (on parlera de sérialisation XML dans ce cas) car beaucoup trop verbeux,
- JSON est plus adapté pour échanger des objets car moins verbeux que XML mais reste propre à Javascript.
Google qui a des besoins assez conséquents d’échange entre ses serveurs et ses systèmes – il est assez simple de se l’imaginer – doit utiliser un protocole qui :
- est petit et économe en termes de bande passante,
- qui se parse rapidement pour “encoder” puis retrouver rapidement ses données,
- est orienté protocole et non contenu.
Protocol Buffers s’utilise de la façon suivante : vous définissez la structure de votre protocole (un fichier avec une extension .proto) et vous générez les classes dans la technologie que vous souhaitez (pour le moment C++, Java et Python). Un peu à la manière d’un stub ou d’un client proxy pour web service, vous avez une définition/contrat et vous en générez un client consommateur. A ce titre Protocol Buffers peut-être assimilé à une technique de génération de protocoles personnalisés. Néanmoins, voici des chiffres qui devraient vous faire réfléchir sur ce celui-ci.
Après quelques heures à faire d’amusement avec Java et PB, voici mon ressenti :
- Général :
- A utiliser uniquement si vous avez un flux d’échange de données objet important, qui ne nécessite pas de structuration XML (validation, requêtage et transformation XSLT),
- Garder JSON, WS & co pour l’échange de données dans les projets de tous les jours,
- +
- Une rapidité de parsing “hallucinante” (si si),
- Une économie de bande passante conséquente,
- Rapidité d’élaboration d’un protocole simple ou complexe,
- Compatibilité des anciennes versions du protocole,
- -
- Pour le moment, manque d’interopérabilité sur les plateformes (C++/Java/Python seulement) et documentation à parfaire,
- Pas de générateur .NET – rien d’étonnant jusque là pour un projet Google – et n’étant pas un fan du C++, je ne m’amuserais pas à modifier le générateur ... (même si j’avoue avoir essayer de modifier un source Java pour le mettre en C#),
- Quelques limitations quand à la mise en place de sous-structure dynamique – on parle bien d’un mode “sérialisation orienté objet”
De ce que j’en déduis après quelques heures d’utilisation, Protocol Buffers fait partie de ces formats/techniques de sérialisation et de définition de protocole comme il n’en existait pas vraiment auparavant et qui manque cruellement encore sur le marché (même si WCF apporte un niveau de facilité et de productivité jamais atteint au niveau de l’échange de données). Un retour plutôt positif en attendant que les choses évoluent ... si elles évoluent.
Les liens :
Les voici :
Et pour finir les deux liens de l’équipe Open XML qui annoncent ma participation dans le développement de PowerTools (eh les gars je mérite pas autant d’égard!).
First, let’s create a profile in order to use PowerTools each time you open a PS console. This is a completely optional step, it’s just for your convenience.
Creating a PowerShell profile
- To check if your profile is already set or not, use: test-path $PROFILE
- If the previous command returns false, then use the command: new-item –path $PROFILE –itemtype file – force
- Once your profile file is created, edit it with notepad (or another text editor) : notepad $PROFILE
- Add the command you think you need each time you use PowerShell (specific key stroke, snapin, etc), for example in our case : Set-ExecutionPolicy unrestricted; Add-PSSnapin OpenXml.PowerTools;
- Save the file
Using PowerTools to lock your documents (read-only)
To lock a WordprocessingML document in read-only mode, use the Lock-OpenXmlDocument cmdlet. This feature is use to prevent people to modify your document (be careful, this command doesn’t add a password protection, just a section lock). Here is an excerpt from the man (Get-Help command with –Detailed argument) :
SUMMARY
Locks one or more Wordprocessing documents.
SYNTAX
Lock-OpenXmlDocument [[-SuppressBackups]] [[-PassThru]] [-Document <OpenXmlPackage[]>] [[-Path] <String[]>] [-WhatI
f] [-Confirm] [<CommonParameters>]
DETAILED DESCRIPTION
The Lock-OpenXmlDocument cmdlet sets a lock inside one or more Wordprocessing documents to prevent them from being edited.
ARGUMENTS
-SuppressBackups
Use this switch to avoid generating backup files for documents specified by the Path parameter. It has no affect on objects piped into this command.
-Document <OpenXmlPackage[]>
Specifies the item(s) from the pipeline that will be modified by this command.
-Path <String[]>
Specifies the path to the item(s) to lock. Wildcards are permitted. If you specify multiple paths, use commas to separate the paths.
-------------- Example 1 --------------
C:\PS>Lock-OpenXmlDocument -Path test1.docx,test2.docx
Sets a lock on test1.docx and test2.docx that prevents them from being modified.
Like the example, run the following command (assuming MyDoc.docx is an existing document in the current directory) to lock the specified file:
lock-OpenXmlDocument -Path 'MyDoc.docx'
Here’ the result :
Sign your documents
The need to sign a document seems obvious today, however Open XML is one of the first office document file format to be ready for this feature. Signing a document is a proof that the document is emitted by the person who said he’s the author and that the document has not been altered during the transport over the wire.
The cmdlet Add-OpenXmlDigitalSignature sign a document by taking the paths of the document to sign and the certificate to use:
Add-OpenXmlDigitalSignature -Path MyDoc.docx' -Certificate 'MyCertificate.pfx'
You can’t use a password protected certificate (hope that this ’bug’ will be resolved soon).
If you want to generate a certificate, use the following commands:
makecert –sv MyKey.pvk –n “CN=<your name>” MyCertificate.cer (when ask for password, don’t enter anything and confirm the “no password protection”)
pvk2pfx –pvk MyKey.pvk –spc MyCertificate.cer –pfx MyCertificate.pfx
Pipelining the cmdlets
So far we have seen how to lock and digital sign a document independently. Now, what about pipelining both cmdlets to lock and sign the document at the same time :
lock-OpenXmlDocument –Path “MyDoc.docx” | Add-OpenXmlDigitalSignature –Certificate “MyCertificate.pfx”
With this kind of command line you can lock and sign every Open XML documents you want to exchange with third parties outside your company. Some feature are still missing in PowerTools like personal information removal but these missing cmdlets will come soon with the new PowerTools team (Eric this is for you !). Oh yes, I forgot to tell you, I recently join the PowerTools virtual dev team (and this is really a great team with talented people), so stay tune !
Après la publication de mon post “Comment monter un serveur Subversion sous Windows en 2 minutes et 1 clic”, voici qu’un camarade de promotion m’a posé une colle : et si je veux créer un repository pour chaque projet indépendant, je fais comment maintenant que mon svnserve/SVNService est configuré ?
Juste pour expliquer le pourquoi de cette question, on peut héberger plusieurs projets dans le même repository, cela permet de n’avoir qu’un batch de sauvegarde et de maintenance ; en revanche, chaque fois qu’une personne commit sur le serveur, c’est le numéro de version de tous les projets qui se voit incrémenter. Difficile par la suite d’avoir des statistiques et un suivi des versions d’un projet spécifique ... Séparer les repository permet d’éviter ce genre de déconvenu au prix d’avoir à maintenir l’ensemble des repository ; ce qui se fait très bien également.
Réponse que je vous fais partager, même si la manipulaiton est triviale, puisque j’y ai perdu 30 minutes de mon temps hier (+10 minutes pour vous la partager) :
- Créez un répertoire racine qui contiendra tous les repository (par exemple c:\svnrepos),
- Dans une console (et si vous avez correctement configuré le PATH) en admettant que vous voulez créer un repository pour le projet projet_1 et projet_2, saisissez :
svnadmin create projet_1
svnadmin create projet_2
Remarque : vous pouvez aussi bien utiliser TortoiseSVN pour créer les repository dans les répertoires - Si vous avez un repository que vous souhaitez y déplacer (je pense à celui créer lors de l’installation de svn1clicksetup), faites un simple déplacer du répertoire du repository dans le répertoire racine,
- Maintenant vient le moment de modifier la configuration du service SVNService (qui vous sert à lancer svnserve en tâche d’arrière plan sur votre serveur) et en particulier le répertoire racine. les arguments derrière -setup ne sont autre que les arguments qui seront passés à svnserve lors de son lancement par le service :
SVNService –setup –d –r “c:\svnrepos” - Redémarrer le service SVNService et vous accéderez aux différents repository avec l’adresse svn://<adresse serveur>/<nom du répertoire du repository>. N’essayez pas d’accéder à svn://<adresse serveur> il n’y aura plus rien à cet emplacement ...
- Vous souhaitez créer un nouveau projet : créer un nouveau répertoire à la racine contenant un repository et le tour est joué !
Une manipulation qui n’a vraiment rien de bien compliquée une fois que l’on à trouver comment changer la configuration de SVNService et de svnserve ...
Il existe beaucoup d’outils indépendants (PackageExplorer, Word Content Control, PowerTools, etc) mais peu qui soient intégrés aux outils existants tels que Visual Studio. En effet si vous travaillez sur des documents dans un projet .NET et que vous double-cliquez sur un document, automatiquement l’IDE lancera l’application associée à l’extension du fichier. Si c’est un document .docx, .pptx ou .xlsx, ce sera respectivement Word, PowerPoint ou Excel qui s’ouvriront.
A l’instar de PackageExplorer ou de XmlSpy, il existe un complément à Visual Studio – nommé Microsoft Visual Studio Tools for the Office System Power Tools ... rien que ça - vous permettant d’ouvrir un document Open XML sous la forme d’une arborescence (répertoires, parties, relations) et d’éditer son contenu à la volée (contenu XML des parties, ajouter/supprimer les relations interne/externe, d’importer ou d’exporter une partie, etc) :
Cet outil gratuit fourni par Microsoft vous permettra de pouvoir rapidement lire/modifier le contenu d’un document Open XML sans sortir de votre outil de production. Même s’il n’est pas aussi puissant que PackageExplorer et XmlSpy, je vous conseille de l’installer, on sait jamais des fois que vous auriez l’envie d’ouvrir un document Open XML directement dans Visual Studio ! Je me surprend toujours à l’utiliser plus que je l’aurais imaginé ...
Téléchargement du Office System Power Tools ici.
Suite au dernier post, voici la suite qui traitera de XPath et des requêtes. Contrairement au post d’introduction, l’ensemble des exemples s’appliqueront maintenant à des documents Open XML (puisque c’est un domaine dans lequel les espaces de noms et les structures sont relativement complexes).
Pour rappel, Linq to XML permet de créer, manipuler du XML de façon intuitive et en un minimum de lignes de code. Par exemple, ici pour générer du RSS en moins de 1 minute (comparer au temps qu’un vous faut pour faire des Append de XmlElement …) :
XDocument doc = new XDocument(
new XDeclaration("1.0", "utf-8", "yes"),
new XComment("Ma feed !"),
new XElement("rss",
new XAttribute("version", "2.0"),
new XElement ("channel",
new XElement("title", "Le blog de Julien Chable"),
new XElement("description", "Le blog de Julien Chable sur le standards, l’interop, Open XML and much more."),
new XElement("link", http://blogs.developpeur.org/neodante),
new XElement("item",
new XElement("title", "Coucou"),
new XElement("description", "COucou super description"),
new XElement("pubDate", DateTime.Now.ToUniversalTime()),
new XElement("guid", Guid.NewGuid())),
new XElement("item",
new XElement("title", "Coucou 2"),
new XElement("description", "Coucou 2 super description"),
new XElement("pubDate", DateTime.Now.ToUniversalTime()),
new XElement("guid", Guid.NewGuid()))
)
)
);
Utiliser les requêtes Linq pour requêter une structure XML
Pour ceux qui connaissent un minimum XPath (notamment les personnes qui font du XSLT), vous savez qu’il existe la notion “d’axe”. Un axe permet de créer une requête dans une direction précise : vers ses ancêtres, ses enfants, ses fères/soeurs, ses descendants, etc …
En réalité Linq est similaire à XPath à plus d’un titre, il est aussi différent sur d’autres points. MSDN fourni un article intéressant à ce sujet, qui vous expliquera bien mieux que ce post, les similitudes et les différences au niveau des axes et d’un tas d’autres choses : http://msdn.microsoft.com/en-us/library/bb675156.aspx. Vous trouverez également de nombreux exemples XPath/Linq to XML à cette adresse : http://msdn.microsoft.com/en-us/library/bb675178.aspx.
En fait pour requêter une structure XML, vous avez 2 façons de le faire et 3 syntaxes au final :
- Utiliser les instructions Linq (from, select, …) directement dans votre code :
// Récupère tous les paragraphes d’un document
var paragraphs = from p in doc.Descendants(w + "p") select p;
- Utiliser les méthodes d’extension (similaire au précédent point) :
- // Récupère tous les paragraphes d’un document
var paragraphs = doc.Descendants(w + "p");
- Utiliser XPath et les méthodes d’extension de System.Xml.XPath : ‘/w:document/w:body/w:p’ ou ‘//w:p’
Le choix entre le point 1 et 2 est juste une question de goût, et personnellement je les utilise en fonction des situations. Comme vous pouvez le constater il est aisé de se déplacer dans l’arbre XML avec les méthodes de la classe XElement imite le comportement de XPath en spécifiant des axes de requêtes et en les cumulant.
Par exemple pour trouver toutes les formes d'une diapositive PresentationML :
foreach (XElement sp in diapDoc.Root
.Element(p + "cSld").Element(p + "spTree").Elements(p + "sp"))
La requête précédente revient à une requête XPath ‘/p:cSld/p:spTree/p:sp’. Nous aurions très bien pu créer une requête de la forme pour aller plus vite me direz vous :
foreach (XElement sp in diapDoc.Root.Descendants(p + "sp"))
Cependant la requête XPath vaudrait ‘//p:sp’ ou ‘/descendant-or-self::p:sp’, ce qui n’est pas forcément ce que l’on voudrait puisque si d’autres éléments <p:sp> du même espace de nom existe à d’autres emplacements dans la structure, il vous seront également retournés.
Utilisation de XPath
Naviguer et requêter avec les méthodes ou les instructions Linq est réellement simple mais quelquefois par simplicité vous aurez besoin de XPath afin de spécifier des conditions ou des expressions qui ne seraient que trop compliquées à réaliser en Linq to XML
Tout d’abord n’oubliez pas d’ajouter l’import de l’espace de nom .NET : System.Xml.XPath; Cela vous donnera accès à 3 méthodes d’extension qui vous servirons bien :
Pour récupérer un identifiant de propriétés (héritage slide –> layout –> master) dans PresentationML :
XElement phLayout = layoutDoc.XPathSelectElement(
String.Format("//p:sp/p:nvSpPr/p:nvPr/p:ph[@idx={0}]",
phElem.Attribute("idx").Value), ...);
Néanmoins, ces méthodes d’extension XPath utilise du vieux pour faire du neuf et si votre structure comporte un espace de nom (en plus de celui par défaut), il va vous falloir comme “à l’ancienne'” utiliser un XmlNamespaceManager (d’où le … à la fin du précédent exemple).
Par exemple pour récupérer tous les éléments de texte de l’avant dernier paragraphe d’un document WordprocessingML :
MainDocumentPart mainPart = wordDoc.MainDocumentPart;
XmlReader reader = XmlTextReader.Create(mainPart.GetStream());
XmlNamespaceManager nsManager = new XmlNamespaceManager(reader.NameTable);
nsManager.AddNamespace("w", w.NamespaceName);
XDocument doc = XDocument.Load(reader);
var pars = doc.XPathSelectElements("//w:p[position()=last()-1]//w:t", nsManager);
foreach (var par in pars)
{
Console.WriteLine(par.ToString());
}
C’est ici que cet article s’arrête, en effet celui n’a pas pour but de présenter Linq to XML, mais son application dans le monde Open XML. Je pense vous avoir convaincu que si vous avez l’occasion d’utiliser .NET 3.5 dans vos projets, la puissance de Linq To XML vous permettra de gagner beaucoup de temps à générer ou manipuler le contenu de vos documents XML.
Vous vous doutez bien que l’on ne peut oublier un tel outil pour manipuler des documents Open XML : Linq to XML. En effet si tous les outils que je vous ai présenté jusqu’à présent (et que je vais continuer à vous présenter) sont utiles, on ne peut les comparer à la productivité que vous donne Linq To XML. Au delà de vous présenter le pourquoi du comment XLinq ou Linq to XML, voici un petit tutorial rapide sur son utilisation avec quelques cas en fin de post pour Open XML.
Tout d’abord, n’oubliez pas l’indispensable import : using System.Xml.Linq;
Créer un document avec un namespace …
XNamespace wygwam = "http://www.wygwam.com";
XElement root = new XElement(wygwam + "Entreprise",
new XElement(wygwam + "Nom", "Wygwam"));
Le résultat :
Très bien, maintenant vous savez comment créer une structure avec un espace de noms par défaut et spécifier celui-ci à des éléments, mais vous ne savez pas encore comment faire pour spécifier le préfixe de l’espace de nom. En effet, Linq to XML crée l’attribut avec l’espace de nom par défaut car il n’en existe pas d’autre et que c’est l’espace de nom par défaut.
Voici la façon de spécifier un espace de nom avec préfixe à la structure XML, et vous vous en rendrez compte, on pourrait penser que XLinq n’a pas été conçu pour les espace de noms (néanmoins détrompez vous en !). En effet, vous devrez vous même les déclarer dans la structure !
L’exemple suivant présente deux intérêts : comment ajouter un élément/attribut et un espace de nom avec préfixe :
XNamespace wygwam = "http://www.wygwam.com";
XElement root = new XElement(wygwam + "Entreprise",
new XAttribute(XNamespace.Xmlns + "wygwam", wygwam.NamespaceName),
new XElement(wygwam + "Nom", "Wygwam"));
Le résultat :
Remarque : gardez bien cet exemple en tête, ses concepts nous serviront pour les requêtes XPath, lesquelles font très attention aux espaces de noms même s’il n’y a aucun préfixe devant …
Maintenant voici comment spécifier deux espaces (un par défaut de nom au sein d’une même structure XML) :
XNamespace microsoft = "http://www.microsoft.com";
XNamespace wygwam = "http://www.wygwam.com";
XElement root = new XElement(microsoft + "Entreprises",
new XAttribute("xmlns", microsoft.NamespaceName),
new XAttribute(XNamespace.Xmlns + "wygwam", wygwam.NamespaceName),
new XElement(microsoft + "Entreprise",
new XElement(wygwam + "Nom", "Wygwam")));
Le résultat :
Si vous voulez préfixer tous les espaces de noms (comme beaucoup de structure Open XML) spécifiez simplement les deux espaces de noms en utilisant XNamespace.Xmlns + <préfixe NS>.
Il existe une autre façon (assez inutile de faire cela, malgré que ce soit comme ça que j’ai commencé à écrire ma première structure XML, avant de comprendre le fonctionnement des espaces de noms des attributs avec XNamespace.Xmlns + <préfixe NS>) c’est en utilisant un XName sous la forme {<nom de l’espace de nom}<nom élement/attribut>. Par exemple : {http://www.wygwam.com}Nom. Néanmoins, comme on s’en doute - merci Reflector – cela prendre du temps à parser et sur des documents Open XML de 30 Mo de texte, les performances s’en ressentent (je m’en suis vite rendu compte …). Vous rencontrerez souvent ces noms complets lorsque vous deboguerez votre code avec des structures contenant de multiple espace de noms.
Exemple Open XML avec le SDK Open XML
Et si je vous disais que seulement quelques lignes suffisent à créer un document Word (si si il s’ouvre dans Word 2007 sans problème) ? Pff diront certains, pourtant :
using (WordprocessingDocument wordDoc =
WordprocessingDocument.Create("MonDoc.docx", WordprocessingDocumentType.Document))
{
// On ajoute la partie principale
MainDocumentPart mainPart = wordDoc.AddMainDocumentPart();
// Création de la structure XML WordprocessingML
XNamespace wNamespace = "http://schemas.openxmlformats.org/wordprocessingml/2006/main";
XDocument xmlDoc = new XDocument(
new XDeclaration("1.0", "utf-8", "yes"),
new XElement(wNamespace + "document",
new XElement(wNamespace + "body",
new XElement(wNamespace + "p",
new XElement(wNamespace + "r",
new XElement(wNamespace + "t",
new XText("Hello Open XML")))))));
xmlDoc.Save(new StreamWriter(mainPart.GetStream()));
}
En remerciant le SDK Open XML v1 et XLinq … XPath et requêtes dans la prochaine partie.
Encore un ! Après les nombreux formats de fichiers devenant l’un après l’autre des normes ISO, c’est au tour du PDF d’Adobe de rentrer dans cette grande famille. Inutile de vous préciser que de ce fait nous parlerons à partir de maintenant du “format PDF” – à moins que le doux nom de ISO 32000 vous plaise - et non du “format Adobe PDF”, puisque l’éditeur en a par conséquent perdu les droits de propriétés qu’il avait dessus.
La version normalisé du PDF est la 1.7 (le PDF/A pour l’archivage est la version 1.4 de Acrobat 5). Le format PDF va donc maintenant évolué au niveau des de l’organisme internationale. Voici l’annonce officielle : http://www.iso.org/iso/pressrelease.htm?refid=Ref1141.
Quand à la compatibilité des logiciels exploitant le format aujourd’hui (Acrobat, PDFCreator, ect … ) nous n’en sommes pas encore là ...
Néanmoins si vous souhaitez prendre posséssion de la spécification, il ne vous en coûtera que 370 francs Suisse. Et oui normalisation et gratuité ne sont pas similaires surtout quand l’'organisme est basé en Suisse !
Comment distinguer les deux normes en vigueur – même si la France n’a pas encore reconnu ni Open XML ni ODF comme norme nationale – et choisir celle qui convient le mieux à votre entreprise et aux individus ? La plupart du temps nous associons simplement le format à un logiciel, et même si au fond l’amalgame « OpenDocument Format de Open Office et l’Open XML de Office 2007 » n’est pas abusif aujourd’hui, il le sera sûrement demain. En effet depuis peu Microsoft a annoncé le support d’ODF dans la prochaine version d’Office – Office “14” - et OpenOffice 3 devrait supporter une partie d’Open XML (au moins en import pour le moment).
Nous nous rendons bien compte que les formats vont devenir aussi différents dans leur implémentation que dans l’association d’un format avec un logiciel spécifique.
La bonne nouvelle : les formats ne seront plus associés à un produit et les utilisateurs pourront choisir la suite bureautique avec laquelle ils souhaitent créer et échanger des documents bureautiques.
La mauvaise nouvelle : les implémentations seront différentes et la compatibilité des implémentations ne sera jamais parfaite. Une solution à cela : les jeux de tests que les organismes de standardisation sont en train d’imaginer/réaliser afin de les intégrer dans les normes en question (à ce titre OOo a déjà fait un petit pas en avant sur la conformité des documents conforme avec OOo : lien)
Identifier le format du document et l’application la mieux adaptée pour l’exploiter
Le premier élément d’identification d’un format est évidemment son extension de fichier. Ce tableau récapitule les offres logicielles les plus utilisées pour exploiter les types de document présentés :
Pour les entreprises : des formats pour quoi faire ?
Nous savons qu’ODF et Open XML ne sont pas des formats d’archivage, et n’ont pas vocation pour le devenir, néanmoins ce sont des formats qui utilisent tous le Zip et le XML comme base et s’accordent sur une utilité : la représentation des documents bureautiques.
Bien que techniquement similaire (enfin si l’on ne regarde que l’utilisation du XML, même la validation de la structure XML n’utilise deux technologies différentes), le format Open XML possède quelques avantages fonctionnels sur ODF :
- Compatibilité avec les documents Office binaires (97-2003) mais aussi les formats antérieurs (Lotus123 ? etc)
- Utilisation de schémas embarqués pour intégrer des données XML métier à un document (aka Custom XML)
- Accessibilité
- Sécurité (signature numérique)
- Des formules compatibles – potentiellement plus compatibles que ODF puisqu’elles sont décrites dans la spécification contrairement à ODF - entre les différentes implémentations,
- Des documents possédant des macros en VBA (la grammaire du langage VBA n’est par contre pas spécifiée dans le standard),
- La possibilité de créer des tableaux croisés dynamiques,
Si vous n’avez pas besoin de ces fonctionnalités et souhaitez juste pouvoir écrire un document dans un traitement de texte des plus classiques, composer quelques formules dans un tableur (attention à la compatibilité avec les différentes implémentations d’ODF) et réaliser quelques présentations : choisissez ODF !
Quelques uns des points (accessibilité, formules et sécurité) devraient être intégrés dans la version 1.2 d’ODF qui est en gestation depuis presque 2 ans et qui devrait sortir vraisemblablement à la fin de l’année. Néanmoins, pour le moment rien n’est fait, ni validé, ni implémenté.
Aujourd’hui, le SEUL avantage d’utiliser ODF pour le moment est de pouvoir utiliser un logiciel de suite bureautique gratuit : OpenOffice, Lotus Symphony, etc
En revanche si Office vous convient, que vous possédez un héritage de documents Office et que tous les points présentés concernant Open XML vous sont indispensable, il n’y a aucun doute que choisir Open XML est une évidence et par voie de fait, de conserver vos suites Office. Si vous possédez encore Office 2003 et n’envisagez pas de migration avant 2009 ou 2010 avec la sortie de Office « 14 », vous pouvez toujours utiliser le pack de compatibilité.
Personnellement, Office 2007 est la première version que je trouve ergonomique, puissante, fiable et de qualité. Pour mon usage personnel (hors cadre entreprise), j’ai toujours utilisé OpenOffice à la place d’Office 2003 ! Que de « bons » souvenirs des bugs de OpenOffice 1.0 … oups je m’égare. Néanmoins aujourd’hui, Office 2007 a pris place sur OOo malgré qu’il soit encore et toujours installé sur mes machines.
Mais avant de donner plus de conclusions, regardons un peu l’état actuel des formats, et comme vous allez le voir ce n’est pas si simple que cela pour chacun.
Quelque soit le format, gare aux versions
Commençons par le format Open XML :
- Format ECMA 376 : les documents créés par Office 2007 dès 2006
- Format IS 29500 « Transitional » : la norme Open XML qui garde la compatibilité avec les anciens formats notamment. Office 2007 est pratiquement compatible avec cette version.
- Format IS 29500 « Strict » : la norme ECMA 376 corrigée suite au BRM ISO : dates non ISO, informations de compatibilité, VML, etc retirés. C’est dans cette version que les nouveaux documents devront être créés. Office « 14 » devrait implémenter cette version d’Open XML.
Pour OpenDocument, ce n’est pas rose non plus, d’autant que le format dépend quand à lui de beaucoup de l’implémentation qu’en fait OpenOffice (les spécifications étant légère, OOo rajoute d’ailleurs de nombreuses balises non documentées pour répondre aux fonctionnalités du produit) :
- Pré ODF - “OpenOffice File Format” : le « OpenOffice File Format » avant sa standardisation et son renommage en OpenDocument. Cette version était implémentée par OOo 1.x avant l’implémentation de ODF standardisé dans OOo.
- Version 1.0 : Standardisé en Mai 2006 par l’OASIS, cette version n’a jamais vraiment été implémentée car trop limitée. Cette version a été rapidement mise à jour – patchée – avec la version 1.1 pour manque de fonctionnalités.
- Version 1.1 : Cette version a fait suite aux limitations de la version 1.0 sans apporter d’innovation notable sur le format et ses fonctionnalités. Les versions actuelles de OOo 2.x utilise un mélange de la versions 1.0 et 1.1 tout en offrant quelques extensions
- Version 1.2 : Réelles améliorations du format dont bon nombre manquait cruellement aux précédentes versions : spécification des formules pour les tableurs, sécurité (signature numérique), accessibilité et métadonnées. Cette version est à ce jour toujours en cours d’élaboration. La prochaine version de OOo, la version 3, devrait implémenter cette version du format.
Garantie de la qualité de l’implémentation
L’OASIS et l’ECMA via des comités ou des groupes de travaux (le DIN allemand par exemple) planchent sur des jeux de tests et de conformité, comme sur les méthodes de conversion des formats entre eux. De côté-là pour le moment : wait and see !
OOo a aussi créé un service en ligne de vérification de conformité des documents ODF.
Le XLSB dans tout ça ?
Le format XSLB est peu connu pour ses capacités. En effet, les formats basés sur XML possèdent un énorme défaut : des performances d’enregistrement et de lecture plutôt médiocres dès que la taille des documents devient importante.
Le format XLSB est un nouveau format de Microsoft depuis la sortie de Office 2007 axé sur les performances d’enregistrement/lecture des documents Excel. Les spécifications ont été rendues publiques récemment. Si vous souhaitez exploiter ce format, vous pouvez télécharger les spécifications et signer une licence d’exploitation ici. A noter que toutes les implémentations Open Source peuvent exploiter ces spécifications « gratuitement » (cf la licence).
Les spécifications des formats DOC, XLS et PPT sont également disponibles (dans une version 1.0, bien meilleure que les brouillons qui étaient disponibles jusqu’à présent), consultez ce post pour plus de précisions.
Conclusion : quel format utiliser et pour quel besoin ?
Pour le moment, l’utilisation d’un format est fortement liée à l’application et donc aux fonctionnalités proposées par le format, et indirectement donc par l’éditeur ou le produit. Dans l’avenir les formats devraient de plus en plus devenir ce qu’ils sont censés être : des formats de documents ! L’objectif de la normalisation d’un format est justement d’offrir une indépendance de ce dernier quant à un éditeur ou une implémentation.
Si aujourd’hui vous avez besoin de :
- Compatibilité avec les documents Office binaires (97-2003) et les formats antérieurs (Lotus123 ? etc),
- Utilisation de schémas embarqués pour intégrer des données XML métier,
- Accessibilité,
- Sécurité (signature numérique),
- Tableaux croisés dynamiques,
- Compatibilité avec les logiciels existants (SharePoint, etc …)
Il est très clairement recommandé de rester avec Office, sinon OpenOffice pourra être utilisé pour vos besoins basiques, souvent ceux d’un particulier. Quand je dis “basique'” ce n’est pas parce que je préfère utiliser la suite de Microsoft aujourd’hui, mais c’est un état de fait : OpenOffice n’en fait pas autant que Office 2007 fonctionnellement (surtout sur les fonctionnalités avancées, clairement orientées entreprise : tableau croisé dynamique, etc).
N’oubliez pas que le format Office est de loin le format d’échange du marché, même si de nombreuses associations tentent de faire croire que ODF s’impose dans le secteur gouvernemental, etc. C’est toujours un fait : le format Office est le format à privilégier en entreprise.
Ne sous estimez pas non plus l’importance de l’ergonomie de l’interface et de la productivité de vos collaborateurs, par exemple, l’ajout d’une image dans OOo est toujours beaucoup plus pénible que dans Office 2007. Si vos collaborateurs sont de grands utilisateurs de la suite bureautique Office, le retour sur investissement devrait s’en faire sentir à la longue.
Egalement un petit feedback de migration des documents Office vers OpenOffice :
- Formez bien vos utilisateurs (apprentissage de l'interface et des fonctionnalités, extension des fichiers, nouveau langage de macro, etc),
- Beaucoup de travail pour refaire toutes la logique métier derrière vos macros,
- Si vos utilisateurs résistent ou sont moins productifs : n’hésitez pas à repasser à Office … et même si les journaux n’en parlent pas, beaucoup le font (sans le dire évidemment) ! Réfléchissez y bien avant de migrer ! Ne le faites pas sur un coup de tête, c'est un choix très lourd sur votre SI et son évolution.
Conclusion : qu’attendre de cette guerre des formats ?
De la concurrence et donc une émulsion technique et fonctionnelle des formats de fichiers de documents numériques. Néanmoins, une fusion des formats dans un avenir proche semble exclue. On pourrait en attendre que du bon, seulement il ne faut pas se voiler la face, la compatibilité des documents et des implémentations n’a pas fini de nous gâcher l'existence …