Comment peuvent ils parler de compatibilité ascendante quand on sait pertinament qu'on ne pourra pas ouvrir un doc office 2003 avec office 95 (
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.
[^] # Re: compatibilité, performance, test
Posté par TImaniac (site web personnel) . En réponse au journal Pourquoi Office 12 ne supporte pas OpenDocument. Évalué à 4.
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.