Zajímalo by mě, kolik kódu bude muset mít číst pracující s OpenXML. Mrňous to zrovna nebude, a zajímalo by mě, jak dobře bude pod Monem chodit binární kód Wordu 95. ;-)
Vzhledem k tomu, že specifikace ma 6000 stran, to mrňous zrovna nebude. První testy ukazují značnou pomalost otevírání OpenXML v OpenOffice. Přepsání do C by jistě pomohlo - Mono byla poslední technologie, na které OpenOffice ještě nezávisel. ;-)
Binární kód Wordu 95 chodit nebude. Debatuje se však o rozšíření ODF, které by umožnilo tagy typu <PokažToJakoWord95> vložit do ODF, aby se při zpětném exportu do OpenXML mohly opět použít, a tím by vznikl zcela identický dokument.
Mno to jo, ale když OpenXML explicitně říká, že pro replikaci části chování máme použít jiné aplikace, jak to udělat? Máme si doplnit neúplnou specifikaci vlastními silami a reverse engineeringem samotných Office?
OpenXML to explicitně říká, ovšem podle mně to nemá ve specifikaci výměnného formátu textových procesorů co dělat. Textový procesor a jeho specifikace není od toho, aby zaručila dokonale stejný vzhled ve všech textových procesorech. To by pak znamenalo dát do specifikace natvrdo i algoritmus zalamování řádku, stran a dělení slov. Dopadlo by to jako TeX, který to sice zaručí, ale nemůže se nikdy upgradovat.
Druhá věc (rozumnější) je zachování speciálních formátovacích značek při exportu mezi formáty. To smysl mít může - protože pak při reexportu do původní aplikace zůstane přesně zachován původní layout.
Také to může pomoci v budoucím rozšíření formátu. Může to být ošidné - podpora rozšíření snadno může vést k nekompatibilitě, nepodporovat rozšíření může znamenat krátkou životnost standardu, pokud se objeví něco zcela nového.