J'ai un peu regarde a cote et en fait la situation est un chouilla plus complique que juste l'ajout de 5 elements pour arriver (suivant eux) a une compatibilite parfaite entre ODF et Microsoft OpenXML. La realite c'est que c'est ce dont leur plugin (da vinci et maintenant ACME) ont besoin de cela pour reproduire le MSOpenXML mais la facon dont ils traduisent le MSOpenXML est un peu comment dire gruik, boite noire et oblige l'achat d'une licence de Microsoft Office (en contradiction flagrante avec le but d'un format interperable). Je cite le Gary en question ( http://docs.google.com/View?docid=dghfk5w9_43f2cmkj ):
As a demonstration that we could in fact hit the high fidelity demanded by MSOffice bound workgroups, we publicly released ACME 376 in December of 2006. ACME produces an XML encoded RTF. Detailed information about this process is available in the Tiffany Letters. The short story is that we've co-opted the same internal conversion process Microsoft uses with the OOXML plug-in.
ACME itself is a pre-processing stage within the da Vinci conversion cycle. When Microsoft applications convert their document in-memory-binary representations to OOXML, they frist convert the imbr to an intermediary stage that we call "MS RTF". It's not open RTF, but something very similar - but very special in that it must be decoded. This decoding is where the name "da Vinci" comes from. The MS RTF is deep with coded secrets and inferred relationships.
What happens is that the ACME pre-processor intercepts MS RTF, and encodes it in XML. Next, the InfoSet engine takes over and is able to pipe that ACME 376 structure into any container able to "hold" the volumes of MS application information. To pipe to ODF, we have to have the iX enhancements. Otherwise, it's like trying to pour a 100 gallons into a quart container. We could pipe to UOF. Or XHTML+. Or HTML+. Or CDF, which happens to be an excellent recipient! Fidelity depends entirely on the file format we are bring to pipe into! Some like CDF are flexible enough to handle the volumes. Others like ODF need to be extended. Which i think, Microsoft has been arguing since day one.
If the Foundation really thinks that they can achieve 100% interoperability with MS Office with just 5 simple changes to ODF, then why the heck don't they just do it? Don't wait for the formality of an the ODF TC 's approval. They should go ahead, as if the standard already had their 5 fixes, and show the world how they have achieved 100% interoperability with MS Office. If they are right, they would all become multi-millionaires in a very short period of time.
)
uniquement par l'utilisation de Microsoft Office et d'une traduction XML d'un format RTF (si j'ai bien compris son systeme) et ceci fait juste une traduction "high fidelity" meme pas parfaite. Suite a cela je suis assez peu etonne par le refus d'ajouter 5 elements qui ne serviront a rien du tout si ce n'est a un plugin closed-source qui de plus necessite Microsoft Office et cela sans aucune preuve que cela ameliore vraiment le rendu. Si il faut uniquement passer par la suite Microsot Office pour arriver a avoir un rendu parfait de Microsoft OpenXML cela prouverait bien que MSOpenXML n'est pas un format fait pour etre utiliser ailleurs que dans cette suite office.
PS: pour une fondation qui pronait un format ouvert, elle n'a jamais publie son plugin de facon open source cela laisse reveur. En gros comme dit par Rob Weir leur participation a ODF fut plus pour critiquer que pour reelement apporter une solution a la perenite des informations dans un format ouvert et interoperable.
[^] # Re: Re:
Posté par abramov_MS . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 2.
J'ai un peu regarde a cote et en fait la situation est un chouilla plus complique que juste l'ajout de 5 elements pour arriver (suivant eux) a une compatibilite parfaite entre ODF et Microsoft OpenXML. La realite c'est que c'est ce dont leur plugin (da vinci et maintenant ACME) ont besoin de cela pour reproduire le MSOpenXML mais la facon dont ils traduisent le MSOpenXML est un peu comment dire gruik, boite noire et oblige l'achat d'une licence de Microsoft Office (en contradiction flagrante avec le but d'un format interperable). Je cite le Gary en question ( http://docs.google.com/View?docid=dghfk5w9_43f2cmkj ):
Donc les elements permettent et cela n'est pas sur de reproduire MSOpenXML dans ODF soi-disant de facon parfaite (quoique comme le dis Rob Weir ( http://www.robweir.com/blog/2007/10/cracks-in-foundation.htm(...) ):
)
uniquement par l'utilisation de Microsoft Office et d'une traduction XML d'un format RTF (si j'ai bien compris son systeme) et ceci fait juste une traduction "high fidelity" meme pas parfaite. Suite a cela je suis assez peu etonne par le refus d'ajouter 5 elements qui ne serviront a rien du tout si ce n'est a un plugin closed-source qui de plus necessite Microsoft Office et cela sans aucune preuve que cela ameliore vraiment le rendu. Si il faut uniquement passer par la suite Microsot Office pour arriver a avoir un rendu parfait de Microsoft OpenXML cela prouverait bien que MSOpenXML n'est pas un format fait pour etre utiliser ailleurs que dans cette suite office.
PS: pour une fondation qui pronait un format ouvert, elle n'a jamais publie son plugin de facon open source cela laisse reveur. En gros comme dit par Rob Weir leur participation a ODF fut plus pour critiquer que pour reelement apporter une solution a la perenite des informations dans un format ouvert et interoperable.