Le document auquel tu fais référence est quand même largement périmé puisque basé sur un des premiers drafts du format Open XML et sur une des premières versions du convertisseur.
On peut clairement y lire des trucs bizzare comme : "Mais il le fait à l'extérieur de Word"
Y'a un plugin pour Word, celui-ci exécute la transfo XML dans le même processus machine que Word. C'est parfaitement transparent pour l'utilisateur.
Mais là, on accumule vraiment les obstacles. La technique qui est au centre de l'OpenXML Translator est la conversion d'un format XML dans un autre à l'aide de filtres XSLT.
C'est oublier que OOo le fait pour de nombreux formats. Techniquement pour convertir un format XML dans un autre, le choix d'XSLT n'es pas du tout abérent, il est même conçu pour.
En effet, en tant que norme d'inter-opérabilité, les schémas Office Open XML sont très pauvres.
Effectivement à l'époque où a été rédigé l'article. Depuis les schémas sont très riches, et l'on y retrouve même des spécifs "oubliés" dans le format OpenDocument, comme le schéma des formules (pourtant indispensable à l'interopérabilité entre 2 tableurs).
D'une part il interdit de profiter de toute la richesse du modèle OpenDocument
suivi de : conçu justement, lui, pour faire abstraction de tout logiciel bureautique, même libre
Faut savoir, soit le format est sémantiquement complet, et la conversion vers Office XML est possible (je dis pas pour l'inverse), soit la couche d'abstraction n'est pas aussi bien faite qu'il le dit.
Et je n'ose pas imaginer dans quelles complications l'utilisateur devra s'embarquer lorsqu'il s'agira d'utiliser ce plug-in avec des versions antérieures d'Office, qui n'ont pas les mêmes fonctionnalités qu'Office 2007 et dont certains outils ne prennent pas nativement en charge le XML.
MS a conçu son format pour supporter l'énorme quantité de documents existant. C'est évident que la compatibilité avec les anciennes versions de MS Office sont fortes. D'ailleur il le dit lui même juste avant l'objectif prioritaire d'Open XML est de favoriser l'intégration entre la suite Office et les applications d'entreprise basées sur les technologies Microsoft.
Cest technologies auquelles il fait référence, ont les même contraintes d'intégrations avec les versions de MS Office actuellement déployés.
Bon et puis depuis cet article, MS a sorti des plugins Open XML pour les suites Office XP et Office 2003.
A ce propos, le rédacteur de cette documentation a préféré dresser la liste de ce qui est supporté, plutôt que celle de ce qui n'est pas supporté, et ce choix laisse vaguement songeur. Cette liste de quelques lignes semble bien légère en regard des 700 pages de la spécification OpenDocument, à laquelle elle ne fait d'ailleurs même pas explicitement référence.
Là encore depuis ca a évolué. D'ailleur à la sorti des spécifs du format Open XML, j'en ai entendu gueuler parcque la doc du format Open XML (plus de 1000 pages si mes souvenirs sont bons) était trop touffue.
Microsoft Office intégrés dans OpenOffice.org (qui, eux, sont réellement natifs et n'encombrent pas l'utilisateur avec des add-ins, add-ons ou autres plug-ins).
Mouarf. Natif. C'est exactement pareil techniquement : il y a une conversion dans le format de représentation des données de OOo, non OOo ne travaille pas directement avec le format de MS en "natif" : il a son propre modèle de données en interne.
Au passage, les prestataires de services favorisés par cette situation seront évidemment les partenaires Microsoft et non pas les spécialistes du format OpenDocument, car le module est fortement lié au framework .Net.
Re-mouarf. La partie liée au framework .NET c'est ca :
convertisseur.source :
inc = load(ooo)
in = decompress(inc)
xsl = load(xslt)
result = doxslTransfo(in, xsl)
compress(result)
Ca c'est fortement lié, on décompresse un fichier, on lance un processus standard et normalisé appelé transformation XSL qui n'a rien de lié au framework .NET et recompresse le résultat.
Enfin effectivement, sur le fond il a raison :
"Car il ne s'agit ni d'une simple transposition syntaxique, ni d'une conversion de structure. Il s'agit de faire correspondre des sémantiques divergentes, ce qui est une autre affaire que le remplacement d'un jeu de balises XML par un autre."
Comme tu le précises, il y aura des pertes. Parcque les formats sont différents, chacun a des fonctionnalités que l'autre n'a pas. Mais au moins ca confirme que MS ne pouvait pas se contenter d'utiliser le format OpenDocument en natif : MS doit gérer une compatibilité avec 90% des suites déployés sur le marché. Ca montre aussi que le format OpenDocument n'a pas été conçu pour être si interopérable que ca, et qu'il ne mérite pas d'être promulger "standard" alors qu'il ne gère pas toutes les fonctionnalités de 90% des suites déployés.
Attention je ne cherche pas à dénigrer le format OpenDocument, sa naissance et sa normalisation sont indispensables, mais ce n'est pas LA réponse à tout. Les suites Office sont avant tout un ensemble de fonctionnalités, le format sous-jacent est là pour "supporter" les informations nécessaires aux fonctionnalités (le format natif). Bref, c'est pas comparable à des formats comme XHTML ou autre PDF qui sont des vrais formats d'interopérabilité. Et ca explique que la création de l'Open XML était de toute façon incontournable. Maintenant on a l'avantage d'avoir 2 grand formats pour 2 grandes classes de suites, et les 2 sont parfaitement librement implémentable. L'interopérabilité ne sera jamais parfaite, mais les migrations seront possibles, et les données ne seront pas "enfermées" dans un format propriétaire, et c'est bien le principal.
[^] # Re: Je sais pas si j'ai tout bien compris...
Posté par TImaniac (site web personnel) . En réponse au journal Novell: encore un pas vers Microsoft. Évalué à 5.
On peut clairement y lire des trucs bizzare comme :
"Mais il le fait à l'extérieur de Word"
Y'a un plugin pour Word, celui-ci exécute la transfo XML dans le même processus machine que Word. C'est parfaitement transparent pour l'utilisateur.
Mais là, on accumule vraiment les obstacles. La technique qui est au centre de l'OpenXML Translator est la conversion d'un format XML dans un autre à l'aide de filtres XSLT.
C'est oublier que OOo le fait pour de nombreux formats. Techniquement pour convertir un format XML dans un autre, le choix d'XSLT n'es pas du tout abérent, il est même conçu pour.
En effet, en tant que norme d'inter-opérabilité, les schémas Office Open XML sont très pauvres.
Effectivement à l'époque où a été rédigé l'article. Depuis les schémas sont très riches, et l'on y retrouve même des spécifs "oubliés" dans le format OpenDocument, comme le schéma des formules (pourtant indispensable à l'interopérabilité entre 2 tableurs).
D'une part il interdit de profiter de toute la richesse du modèle OpenDocument
suivi de :
conçu justement, lui, pour faire abstraction de tout logiciel bureautique, même libre
Faut savoir, soit le format est sémantiquement complet, et la conversion vers Office XML est possible (je dis pas pour l'inverse), soit la couche d'abstraction n'est pas aussi bien faite qu'il le dit.
Et je n'ose pas imaginer dans quelles complications l'utilisateur devra s'embarquer lorsqu'il s'agira d'utiliser ce plug-in avec des versions antérieures d'Office, qui n'ont pas les mêmes fonctionnalités qu'Office 2007 et dont certains outils ne prennent pas nativement en charge le XML.
MS a conçu son format pour supporter l'énorme quantité de documents existant. C'est évident que la compatibilité avec les anciennes versions de MS Office sont fortes. D'ailleur il le dit lui même juste avant
l'objectif prioritaire d'Open XML est de favoriser l'intégration entre la suite Office et les applications d'entreprise basées sur les technologies Microsoft.
Cest technologies auquelles il fait référence, ont les même contraintes d'intégrations avec les versions de MS Office actuellement déployés.
Bon et puis depuis cet article, MS a sorti des plugins Open XML pour les suites Office XP et Office 2003.
A ce propos, le rédacteur de cette documentation a préféré dresser la liste de ce qui est supporté, plutôt que celle de ce qui n'est pas supporté, et ce choix laisse vaguement songeur. Cette liste de quelques lignes semble bien légère en regard des 700 pages de la spécification OpenDocument, à laquelle elle ne fait d'ailleurs même pas explicitement référence.
Là encore depuis ca a évolué. D'ailleur à la sorti des spécifs du format Open XML, j'en ai entendu gueuler parcque la doc du format Open XML (plus de 1000 pages si mes souvenirs sont bons) était trop touffue.
Microsoft Office intégrés dans OpenOffice.org (qui, eux, sont réellement natifs et n'encombrent pas l'utilisateur avec des add-ins, add-ons ou autres plug-ins).
Mouarf. Natif. C'est exactement pareil techniquement : il y a une conversion dans le format de représentation des données de OOo, non OOo ne travaille pas directement avec le format de MS en "natif" : il a son propre modèle de données en interne.
Au passage, les prestataires de services favorisés par cette situation seront évidemment les partenaires Microsoft et non pas les spécialistes du format OpenDocument, car le module est fortement lié au framework .Net.
Re-mouarf. La partie liée au framework .NET c'est ca :
convertisseur.source :
inc = load(ooo)
in = decompress(inc)
xsl = load(xslt)
result = doxslTransfo(in, xsl)
compress(result)
Ca c'est fortement lié, on décompresse un fichier, on lance un processus standard et normalisé appelé transformation XSL qui n'a rien de lié au framework .NET et recompresse le résultat.
Enfin effectivement, sur le fond il a raison :
"Car il ne s'agit ni d'une simple transposition syntaxique, ni d'une conversion de structure. Il s'agit de faire correspondre des sémantiques divergentes, ce qui est une autre affaire que le remplacement d'un jeu de balises XML par un autre."
Comme tu le précises, il y aura des pertes. Parcque les formats sont différents, chacun a des fonctionnalités que l'autre n'a pas. Mais au moins ca confirme que MS ne pouvait pas se contenter d'utiliser le format OpenDocument en natif : MS doit gérer une compatibilité avec 90% des suites déployés sur le marché. Ca montre aussi que le format OpenDocument n'a pas été conçu pour être si interopérable que ca, et qu'il ne mérite pas d'être promulger "standard" alors qu'il ne gère pas toutes les fonctionnalités de 90% des suites déployés.
Attention je ne cherche pas à dénigrer le format OpenDocument, sa naissance et sa normalisation sont indispensables, mais ce n'est pas LA réponse à tout. Les suites Office sont avant tout un ensemble de fonctionnalités, le format sous-jacent est là pour "supporter" les informations nécessaires aux fonctionnalités (le format natif). Bref, c'est pas comparable à des formats comme XHTML ou autre PDF qui sont des vrais formats d'interopérabilité. Et ca explique que la création de l'Open XML était de toute façon incontournable. Maintenant on a l'avantage d'avoir 2 grand formats pour 2 grandes classes de suites, et les 2 sont parfaitement librement implémentable. L'interopérabilité ne sera jamais parfaite, mais les migrations seront possibles, et les données ne seront pas "enfermées" dans un format propriétaire, et c'est bien le principal.