Akiben felmerül, hogy a szabványos formátumot válassza a zárt helyett, óhatatlanul felteszi a kérdést: miért bánnak olyan rosszul az ODF-fel azok az irodai csomagok, amelyeknek az OOXML a natív formátuma?

A két legkézenfekvőbb válasz a következő. Vagy a gyártók elhanyagolták a formátumot, és csak utólagos szempontként kezelik. Vagy csendben azon dolgoznak, hogy lejárassák az átlátható interoperabilitás gondolatát, mégpedig olyan rossz támogatással, amely „bebizonyítja”, hogy a formátum nem működik.

Mindkét magyarázat túl egyszerű. A valóságban három különböző mechanizmus hat egyszerre, gyártónként eltérő arányban, de végül ugyanoda futnak össze.

Egy kihívás, ami valójában nem az

Önmagában, elszigetelten nézve az ODF hűséges olvasása és írása valóban megoldható feladat: a formátum teljes egészében és nyíltan dokumentált, és nincs benne az OOXML hírhedt „legacy” kompatibilitási zászlóinak megfelelő rész, amelyek régi Microsoft-termékek nem dokumentált viselkedésére hivatkoznak, és amelyeket csak a Microsoft tud pontosan reprodukálni.

Egy hozzáértő fejlesztőcsapat pusztán az ODF specifikáció alapján is helyesen meg tudja valósítani az ODF támogatását.

Egy irodai csomag azonban nem önmagában egy formátumot valósít meg: van egy belső, memóriában tárolt dokumentummodellje. A dokumentum betöltése ennek a modellnek felelteti meg a fájlt, a mentés pedig ebből a modellből készít fájlt.

A hűség akkor a legnagyobb, ha a belső modell szerkezete illeszkedik a dokumentumformátumhoz. A LibreOffice modellje lényegében maga az ODF, ezért ebben az értelemben az ODF valóban natív formátum.

Ha egy csomag belső modellje OOXML-szerkezetű, az ODF már nem natív, hanem külső formátum lesz, amelyet egy másik formátumhoz tervezett reprezentációra kell oda-vissza átalakítani.

Nézzünk egy olyan ODF funkciót, amely OOXML-ben nem létezik: az ODP mezőt, amely a diák teljes számát jeleníti meg. A tanulságos rész az, hogy maga az információ nem hiányzik a PPTX fájlból. A csomag felsorolja az összes diát, a darabszám pedig bármelyik program számára elérhető, amely megnyitja. Amit az OOXML nem tud kifejezni, az az állítás, hogy ez a szám a teljes diákszám. Van mező az aktuális diaszámnak, de nincs a darabszámnak, és a Microsoft saját útmutatása szerint a felhasználó írja be a számot egy szövegdobozba, és kézzel tartsa karban. Ez pontosan annak a leírása, hogy valójában nincs mező. Az összes ismert kerülőmegoldás makró vagy bővítmény, amely egyszer kiszámolja a számot, majd rögzített szövegként beírja.

Amikor tehát egy ilyen mezőt tartalmazó ODP fájlt OOXML-alapú szerkesztőben nyitnak meg, nem az adat vész el, hanem az utasítás. A szám megmarad. Az a tény, hogy számolt érték volt, nem. Ettől a pillanattól a dokumentum már nem tudja, hány diából áll.

A fordított irány csendesebben, és ezért rosszabbul hibázik. Ha az Impress PPTX-be exportálja a diákszámot, azt rögzített szövegként kell kiírnia, így az előadás a konvertálás napján még helyes, de az első dia hozzáadásakor vagy törlésekor már hibás. Egy szám, amelyet már nem számol a program, de még hihetőnek látszik, károsabb, mint egy látványos hiány, mert semmi nem jelzi a dokumentumban, hogy ellenőrizni kellene.

Egy ODF-alapú szerkesztő egészen másként kezeli a fordított esetet. Ha olyan funkcióval találkozik, amely az egyik formátumban létezik, a másikban nem, az adatot félreteszi, nem pedig eldobja, és visszaállítja, amikor a dokumentum visszakerül OOXML-be. A LibreOffice-ban ennek neve is van: grab bag. Ez az import szűrők dokumentált része, nem mellékes mellékhatás.

A különbség nem az import szűrő minőségében rejlik, hanem abban, hogy az architektúrát eleve úgy tervezték, hogy megőrizze a másik formátum jelentését.

Ez azért fontos, mert azt jelenti, hogy az OOXML-alapú csomagok gyenge ODF támogatása nagyrészt már azelőtt eldől, hogy egyáltalán felmerülne a szándék kérdése. A nehézség nem abszolút, hanem ahhoz az architektúrához viszonyított, amelyet a gyártó választott.

Három mechanizmus

Első: a fogadás egy referenciaformátumra. Vannak csomagok, amelyek egyáltalán nem számolnak az ODF-fel, mert az értékajánlatukat a másik formátumra építették.

Az OnlyOffice a legvilágosabb példa, mert OOXML köré építették, és minden más formátumot ebbe a modellbe konvertál. Az ODF így eleve másodrendű import- és exportformátum.

A WPS Office-t azért hozták létre, hogy a docx, xlsx és pptx fájlokat hűen megnyissa. Az ODF funkciói a Microsoft OpenXML projektjének bővítményéből származnak, és csak 2022 májusában építették be az alkalmazásba, egy olyan konverziós rétegként, amely ODF 1.1-re készült, vagyis a szabvány 2007-es változatára. A tizenöt évnyi lemaradást már a kiadás napján belekódolták.

A Google Workspace ugyanezen logika egy változata, nem kivétel. A belső modellje sem ODF, sem OOXML, hanem egy saját, webes reprezentáció, és mindkét formátum egy konverziós rétegen keresztül jut el hozzá. Egy közigazgatási szerv számára a következmény ugyanaz: a nyílt szabvány csak exportcél, nem az a közeg, amelyben a szoftver „gondolkodik”.

Ezeknél a gyártóknál az ODF soha nem volt része a stratégiának. Az ajánlatuk az, hogy a Microsoft dokumentumait a Microsoft Office-tól eltérő programmal lehessen megnyitni, és hogy azok jól nézzenek ki. A gyenge ODF támogatás közvetlen következménye ennek a stratégiának.

Második: tudatos alulfinanszírozás. Valószínűleg ez az ok az egész irodai csomag szektorban jelen van. Bár az ODF-et könnyebb és olcsóbb helyesen megvalósítani, a folyamat így is fejlesztési, tesztelési és karbantartási költségekkel és ütemezéssel jár, hogy lépést tartson a folyamatosan fejlődő szabvánnyal.

Ha egy gyártó felhasználói többnyire docx fájlokat cserélnek, a kiváló ODF támogatás többlet-üzleti értéke gyakorlatilag nulla. Így az ODF-et először csak minimális szinten valósítják meg, majd csendben hagyják leromlani.

Az a benyomás, hogy az ODF támogatás nem számít, önmagában egyetlen cég piaci fölényének következménye, és kettős hatása van. A bezártság, a lock-in olyan szoftverfunkcióvá válik, amelyet a piac teljesen természetesnek tekint, az ODF pedig törékenynek tűnik, anélkül, hogy ehhez külön lejárató kampányra lett volna szükség.

Harmadik: szándékos lejáratás. Ez a mechanizmus valós, és közvetlenül a Microsoftot érinti, az Office 2007 Service Pack 2-jével. Az abban szállított ODF támogatás két, egymásnak ellentmondó irányban is kudarcot vallott.

Ha az Excel egy másik alkalmazás által készített ODF táblázatot olvasott be, csendben eltávolította a képleteket, és csak az egyes cellák utolsó értékét tartotta meg. Rob Weir akkori értékelése szerint így a dokumentum puszta „számtáblázattá” vált, a számítási logika nélkül. Íráskor az Excel a képleteket egy Excel-namespace-be tette, amely sem nem az volt, amit az OpenOffice és a többi ODF alkalmazás használt, sem az OOXML-é. Azok az alkalmazások, amelyek ellenőrizték a namespace-t, egyszerűen elutasították a dokumentumot; amelyek nem ellenőrizték, hibás fájlt mutattak, amelyben sem a képlet, sem az érték nem jelent meg helyesen.

Ez tankönyvi példája annak, hogyan lehet lejáratni az interoperabilitást: a formátumkövetelmény teljesítése papíron, olyan megvalósítással, amely láthatóan hibás fájlokat gyárt, és mindenki számára azt demonstrálja, hogy az ODF valójában nem működik.

A Microsoft akkor azzal érvelt, hogy az ODF szabvány nem definiálja a táblázatkezelő képleteket, amelyek csak az ODF 1.2-ben jelentek meg, így nem volt mire támaszkodni. Ez az érv nem állja ki a Microsoft saját válaszának próbáját. Doug Mahugh, a Microsoft evangelistája Weirnek válaszolva egymás mellé tette a két viselkedést: ugyanazzal az ismeretlen képletszintaxissal szembesülve az IBM Lotus Symphony megőrizte a képlet jelölését, az Excel pedig a gyorsítótárazott értékeket. Egyik alkalmazásnak sem volt követhető specifikációja. Csak az egyiknek volt olyan architektúrája, amelyben volt helye annak, amit nem értett.

Érdemes megfigyelni, mit tartott meg az Excel. Nem a képletet, hanem az utolsó eredményét. Ugyanaz az egyszerűsítés, mint a diákszám esetében, csak más alkalmazásban. Az OOXML-re formált modell megőrzi az értéket, de elveszíti a számítást, amely előállította, és egy olyan dokumentum, amely csak az utolsó eredményeire redukálódik, már nem képes önmagát helyesbíteni.

Ez az epizód tizenhét éves, és könnyű lenne történelmi érdekességként félretenni. A Microsoft Office ma már ODF 1.4 támogatást deklarál. Ami javult, az a névleges megfelelés, nem az architektúra. A belső modell továbbra is OOXML, és minden ODF dokumentum, amely átmegy rajta, továbbra is fordítás.

Összegzés

A gyenge ODF támogatás nem a formátum technikai elmarasztalása, hanem egy olyan piac látható lenyomata, amelyet egyetlen gyártó dominanciája formált, és ez a helyzet nem véletlenül alakult így.

Európai közigazgatási szervek számára ez átírja a gyakorlati kérdést. Az interoperabilitási problémák, amelyekkel az ODF nyílt szabványra való átálláskor szembesülnek, nem az ODF hibái, az ODF teljesen készen áll. Ezek a problémák azt bizonyítják, hogy a legtöbb elérhető eszközt eleve más formátum natív kezelésére tervezték, és az az egyetlen gyártó, amelynek hatalmában állna ezen változtatni, ezt többször is elmulasztotta megtenni.

Az ODF piaci támogatásának ingatag állapota nem ok arra, hogy halogassák a szabvány bevezetését, hanem a lehető legerősebb érv amellett, hogy kötelezővé tegyék – és pontosan határozzák meg, hogyan.

Az a kérdés védi meg egy közintézmény dokumentumait és felette gyakorolt szuverenitását, hogy nem egyszerűen „támogatják-e” az ODF-et, hanem hogy ez a támogatás natív-e. Vagyis az, hogy a szoftver saját belső modellje maga a nyílt szabvány-e, vagy a szabvány csak idegen elem egy olyan motorban, amelyet valami másra terveztek.

A dokumentumformátum az igazgatási folytonosság és a közös emlékezet alapja. Olyan eszközöket választani, amelyek számára a nyílt szabvány a natív formátum, nem két egyenértékű opció közötti ízlésbeli döntés, hanem a különbség aközött, hogy birtokoljuk-e a dokumentumainkat, vagy csak bérbe vesszük a hozzáférést attól, aki azokat a formátumot irányítja, amelyben valójában íródnak.