Wojna rozpętała się gdy tylko Microsoft zgłosił swój format dokumentów OpenXML do procesu standardyzacji. Pierwsza bitwa została przegrana - Microsoft zarejestrował OpenXML jako standard ECMA. Wiadomo jednak, że do pewnej klasy powaznych zastosowań konieczne jest posiadanie standardu ISO. I ta bitwa się dopiero rozgrywa - OpenXML jest na etapie głosowania w ISO (OpenXML ma się stać normą ISO 29500). Wojna dotarła także do Polski - Polski Komitet Normalizacyjny widząc co się dzieje poprosił o konsultacje środowiskowe.

Jako członek zarządu polskiego ISOC wielokrotnie zabierałem głos w tej sprawie, sugerując że nie należy się przyłączać do ogólnoświatowej nagonki na OpenXML. Jest to opinia odosobniona i nader niepopularna w środowisku open-source, z którym do niedawna się identyfikowałem. Na moje stanowisko wpłynęło kilka czynników. Przede wszystkim, dyskusja nie toczy się na jakiejś abstrakcyjnej warstwie ogólnie pojętych formatów, ani tym bardziej warstwie ideologicznej. Mówimy o realnych dokumentach, które ktoś będzie musiał zapisywać i czytać.

Jeśli popatrzymy na strony takie jak No OOXML czy EOOXML Objections to znajdziemy tam setki niezwykle poważnie brzmiących zarzutów wobec formatu OpenXML. Jednak analiza kilku z nich nastroiła mnie bardzo nieufnie do zebranej tam argumentacji. Na przykład, jako jeden z zarzutów wymienia się ze specyfikacja OpenXML jest.. zbyt obszerna bo liczy 6 tys. stron. Warto sobie zadać pytanie, dlaczego tak jest? Jeśli ktoś zada sobie trud przejrzenia tej dokumentacji, to zauważy że jest ona bardzo drobiazgowa i stara się możliwie jednoznacznie wyjaśnić wszelkie wątpliwości w interpretacji poszczególnych pól. Dla porównania specyfikacja ODF to 800 stron. Czy autorzy ODF pisali lepiej, zwięźlej, precyzyjniej?

No cóż, sprawdźmy. Osobiście wziąłem na warsztat pole Protected Document, które chroni przed modyfikacjami komórkę arkusza kalkulacyjnego za pomocą hasła. Nieprzypadkowo, bo jeden z zarzutów ze strony Grokdoc dotyczy właśnie tego pola, które w specyfikacji OpenXML określa że powinno ono zawierać "skrót hasła" i pokazuje przykładowy (sic!) algorytm skrótu (hash). Grokdoc informuje o tym w histerycznym tonie ("immediate risk", "passwords may be determinable") i poświęca pół strony na wyjaśnienie jak powinno być to zrobione poprawnie powołując się na ISO, NESSIE, NIST itd.

Na chłopski rozum w ODF powinno być to zrobione właśnie tak jak trzeba, czyli bezpiecznie. I tutaj właśnie wychodzi cała mizeria argumentacji przeciwstawiajacej "immature and incosistent" (niedojrzały i niespójny) OpenXML światłemu formatowi ODF. Dlatego że cała sekcja opisująca komórkę analogiczną do Protected Document (sekcja 8.5.1 w ODF 1.1) zajmuje całe TRZY zdania. Czy wskazuje na bezpieczne funkcje skrótu, które tak wzburzyły krytyków z Grodoc? A gdzie tam - ODF opisuje to tak: "a hash value of the password is stored". To tyle na temat ""mature and consistent".

Z analizy wymagań wobec dokumentu elektronicznego, którą sporządziłem na własne potrzeby rok temu, wynikały z niej konkretne wymagania wobec dokumentu elektronicznego, który miałby być stosowany w polskiej administracji publicznej i kontaktach biznesowych (np. e-fakturowanie). Wśród nich jest obsługa bezpiecznego podpisu elektronicznego. OpenXML (ECMA 376) posiada w specyfikacji podpis elektroniczny w formacie XML-DSig, tak jak i np. szyfrowanie dokumentu. Analizując obie specyfikacje, ku swojemu zdumieniu, stwierdziłem, że ODF (ISO 26300) takiej funkcjonalności NIE POSIADA! Po prostu, podpisu elektronicznego nie ma w specyfikacji ODF 1.0. Chociaż szyfrowanie jest. Dlaczego? Nie wiadomo. Podobno podpis ma być w ODF 1.2 - ale ODF 1.2 nie jest normą ISO. Ba, na razie w ogóle nie istnieje.

Czy norma ISO 26300 nadaje się zatem do bezpośredniego zastosowania w administracji publicznej czy fakturowaniu elektronicznym? W przetargu nie można podać specyfikacji "zgodny z normą ISO 26300" bo dostaniemy produkt niezgodny z ustawą KPA i ustawą o informatyzacji. Należałoby zażądać specyficznej dla programu OpenOffice wersję ODF, która podpis posiada - ale to już nie jest ISO 26300. Albo brać dokument ODF i podpisywać go zewnętrznie. Tak czy inaczej normalizację szlag trafia, na złość Microsoftowi odmrozimy sobie uszy.

Najbardziej rażące jest tutaj stosowanie podwójnych standardów, tak jakby wygrana ODF była celem ideologicznym, w imię którego warto poświęcić obiektywizm i racjonalność oceny. Gdy mówi się o problemach licencyjnych OpenXML, nikt przezornie nie wspomina o problemach z patentami Suna w ODF. Gdy krzyczy się wielkim głosem o "niedopracowaniu" OpenXML, wszyscy milczą o brakach ODF - informacja o braku podpisu elektronicznego w ODF pojawiła się na Wikipedii, dopiero wtedy, gdy... ją tam dodałem. Gdy mówi się o tym, że OpenXML odwołuje się do niezdefiniowanych standardów, wszyscy jak jeden mąż zapominają że ODF w analogiczny sposób odwołuje się do formatu archiwum ZIP, którego jedyna definicja w normach międzynarodowych to - paradoksalnie - specyfikacja ECMA 376 czyli "wrogi" OpenXML.

Nie wiem czy MS OpenXML jest lepszy od ODF, czy też może ODF jest lepszy od OpenXML. Na podstawie dotychczasowych doświadczeń mogę powiedzieć, że oba są w jakimś stopniu niedopracowane. Jednak przeciwieństwie do adwokatów ODF nie mam śmiałości by uczciwie bronić tego formatu, bo jest on w mojej opinii nawet bardziej niedopracowany niż OpenXML. Format dokumentu jest narzędziem, a nie celem samym w sobie. Z mojego punktu widzenia świadome ukrywanie słabości standardu upośledzonego jakim jest ODF tylko po to by odrzucić konkurencyjny OpenXML jest działaniem irracjonalnym.