| Ha hivatalos dokumentumokról van szó, a közigazgatási szervek két ISO/IEC szabvány közül választhatnak. Ezek közül csak az ODF-ről (ISO/IEC 26300) mondható el, hogy szállítófüggetlen, nyílt, és megbízhatónak bizonyult az évek és szoftververziók váltakozásában, valamint különböző szoftvertermékek által támogatott. A későbbi OOXML szabvány (ISO/IEC 29500), melyet eredetileg egyetlen szoftvercég fejlesztett ki, három különböző verzióban valósul meg, („ECMA”, „Transitional” és „Strict”), és ezek nem kompatibilisek egymással. Annak ellenére, hogy a „Transitional” és az „ECMA” verziók elavultak – a „Transitionalt” csak ideiglenes megoldásként fogadták el, időt adva ezzel a szoftverforgalmazónak a „Strict” bevezetésére a termékeiben – továbbra is használatban van mindkettő. Ennek az az oka, hogy a forgalmazó irodai csomagjának (MS Office) régebbi verziói nem tudják olvasni és szerkeszteni az OOXML Strictet, és nem valószínű, hogy valaha szert tesznek ilyen képességekre.Ez a következetlenség számos problémát okoz a szabad és nyílt forráskódú irodai alkalmazások fejlesztőinek: |
Emiatt a mai napig nincsenek olyan szabad és nyílt forráskódú megoldások, amelyek teljes mértékben támogatnák az OOXML-t. A dokumentumformátummal kapcsolatos problémák negatívan érintik a közigazgatást is. Archiválási szakértők arra figyelmeztetnek, hogy az OOXML verziók közti ellentmondások problémákat okozhatnak a régebbi dokumentumoknál, így előfordulhat, hogy a felhasználók nem tudják megnyitni azokat, vagy dolgozni velük. Egyetemi kutatások bizonyítják, hogy még a forgalmazó saját termékei sem tudják megfelelően kezelni a különböző OOXML-funkciókat. |
|
| „Senki nem használ kizárólag OOXML Strictet”
– Michael Meeks, LibreOffice fejlesztő |
Bevezetés: Miért nem fog elcsendesedni ez a vita
Az OOXML kifejlesztése 2004-ben kezdődött ECMA Internationalnél (korábban European Computer Manufacturer’s Association), ami egy privát, tagságon alapuló, nonprofit szabványügyi szervezet. Két évvel később az ECMA kapcsolatba került az ISO nemzetközi szabványügyi szervezettel, amely különböző nemzeti szabványügyi szervezetek képviselőiből áll. Az OOXML (más néven Office Open XML) ipari szabvánnyá vált, csakúgy, mint az ODF, az Open Document Format, amit számos különféle termék alkalmaz, többek között a LibreOffice, az Apache OpenOffice, valamint a Google Docs.
Az OOXML eredeti alkotója, a Microsoft ígérete szerint a szoftverei teljes mértékben támogatják az OOXML-t, mint a „legtöbbet használt dokumentum szabványt”. Azonban a szabványt egyre növekvő vita övezi. Mind a függetlensége, mind a más programokban való alkalmazása heves vita tárgyává vált a szabad és nyílt forráskódú szoftverek fejlesztői és közigazgatási szervek körében.
Michael Meeks egyike a LibreOffice fő fejlesztőinek. Korábban a SUSE-nél, jelenleg pedig a LibreOffice-t támogató Collabora cégnél dolgozik. Meeks meg van róla győződve, hogy az OOXML-t (ISO 29500) nem használják „a valóságban”, és állítása szerint soha nem lesz a Microsofttól független OOXML szabvány. Ellenben az ODF a hosszú távú dokumentumszerkesztésre és archiválásra alkalmas szabvány. Az ODF-et számos szervezet támogatja, köztük több nagy ICT-cég, míg az egyetlen OOXML-t támogató szervezet maga a kizárólagos tulajdonos.
„Senki nem használ kizárólag OOXML Strictet”
Továbbá, Meeks szerint „roppant valószínűtlen, hogy bármilyen közigazgatás valóban csak az ISO kompatibilis OOXML Stricttel dolgozzon”. Az intézményeknek lehetnek régi MS Office-t használó dolgozói, vagy dolgozhatnak régebbi dokumentumokon. Dokumentumokat váltanak a polgárokkal, cégekkel, vagy más közigazgatási szervekkel, akik olyan irodai alkalmazásokat használnak, amik nem támogatják teljes mértékben az ISO 29500-at, így megszakad az OOXML Strict dokumentumok lánca, gyakran a felhasználók tudta nélkül. „Ha egy cég, vagy szervezet – folytatja Meeks – az MS Office különböző verzióit használja, beleértve a régebbi változatokat, mint az MS Office 2007 vagy 2010, akkor a több kézen áthaladt dokumentumok nem felelnek meg az OOXML ISO 29500 által definiált ISO Strict szabványának”.
Egy cég vagy önkormányzat átlagos napi ügyfelekkel, lakossággal, vagy partnerekkel történő munkája során az OOXML körüli összeférhetetlenségek előbb vagy utóbb problémákhoz vezetnek. Például gyakori, hogy egy adott dokumentum MS Office 2013-mal készült, majd egy olyan kolléga szerkeszti és menti újra, aki MS Office 2007-et vagy 2010-et használ. Mivel a Microsoft Office régebbi verziói nincsenek összhangban a legújabb, „Strict” OOXML szabvánnyal, esélyes, hogy a dokumentum körforgása során metaadatok vesznek el. És, mivel a Microsoft által használt „Strict” szabvány még mindig nem teljesen dokumentált és publikus – például hivatkozásokat tartalmaz Microsoft-weboldalakra, melyeknek egy része már nem létezik – a konvertálás során gyakori és sokat taglalt jelenség az adatvesztés. Tovább ront a helyzeten a hibaüzenetek hiánya, valamint a fájlkiterjesztés (például .docx a szöveges dokumentumoknál), ami nem mutatja meg a felhasználónak, milyen formátumban került mentésre a dokumentum.
„Bár az OOXML Strict szabvány elviekben megvalósítható nyílt forráskóddal, a specifikációja olyan összetett, hogy rengeteg részletet kellene újraimplementálni az MS Office-ból, hogy megfelelő legyen”, mondja Meeks. De még nagyobb problémát jelent a Meekshez hasonló fejlesztőknek az OOXML támogatása a mindennapokban, a különböző dialektusokkal és a különböző irodai programcsomagokban való támogatottságukkal. „Számomra rejtély, hogy miért ad valaki egy egyedüli, domináns forgalmazónak ekkora előnyöket egy dokumentum megvalósításában, mikor előírható jobb, nyíltabb dokumentumszabvány, amely megvalósítása széleskörűbb támogatottsággal bír ”, mondja.
Komplex örökség
Svante Schubert, az OASIS ODF TC tagja, egy másik veterán mérnök az OpenOffice-től, aki irodai programcsomagok együttműködésén dolgozik, egyetértését fejezte ki: „Kifejleszthetsz egy OOXML kompatibilis alkalmazást, ami az OOXML összes szükséges tulajdonságát fedi, de ez az alkalmazás nagy valószínűséggel nem lesz kompatibilis a létező OOXML dokumentumok zömével.”
Ez a specifikációban rejtőző „választható tulajdonságoknak” köszönhető. Soknak történelmi háttere van, és felesleget képeznek az OOXML-ben. „A rengeteg példa közül vegyük a táblázatokat. Miért van három különböző táblázatformátum az OOXML-ben? Egy a Wordhöz, egy az Excelhez, és egy a PowerPointhoz. A válasz: mert három különböző részleg dolgozott egymástól függetlenül a formátumon. A Microsoft külön-külön vásárolta meg vagy fejlesztette ki ezeket a termékeket, és a specifikációban integrálniuk kellett ezt a három megközelítést egyetlen XML-ben.
Fejlesztők és szabványügyi szakértők egyetértenek abban, hogy a szabványosításnak nem így kellene zajlania. Schubert állítása szerint az ilyen példák arról tanúskodnak, hogy az OOXML szabványt egy szoftvercég szükségletei határozták meg, sokkal inkább, mint a normál ipari szabvány procedúrák és ideálok. „Ezzel szemben az ODF-nek egyetlen táblázatleírása van. Azért fejlesztették ki, hogy biztosítsa a kompatibilitást, és különféle alkalmazáselemek között használják.
Az Európai Bizottság egy, az Európai Digitális Menetrend 23-as intézkedésének részét képező jelentése megerősíti ezt az érvet. A dokumentum rámutat, hogy az OOXML számos komoly alkalmazási akadályt tartalmaz. A Guidelines for Public Procurement of ICT Goods and Services: SMART 2011/0044 című végső jelentésükben kijelentik: „Noha a hivatalos szabványügyi szervezeteken keresztül bevezetett szabványok keresztülmennek egy hivatalos fejlesztési eljáráson, így is tartalmazhatnak akadályokat, amelyek megnehezítik az érdekelt felek általi megvalósítását. A jelentés az OOXML szabvánnyal szemlélteti ezt (32-es lábjegyzet). „Például az ISO szabvány (ISO/IEC 29500) dokumentumformátumokhoz. Ezen ISO szabvány technikai leírása tulajdonosi technológiára vonatkozó hivatkozásokat tartalmaz, valamint konkrét termékek márkaneveit. Továbbá, a szóban forgó ISO szabvány leírása nem teljes: például a technikai leírás a forgalmazó honlapján lévő weboldalakra irányító külső hivatkozásokat tartalmaz, amely oldalak jelenleg nem érhetők el.”
Mivel az OOXML ennyire heterogén és félreérthető szabvány, és a Microsoft tartja kezében a gyeplőt, és nem frissíti a korábbi szoftververziókat, minden szoftverfejlesztőnek szembe kell néznie az egyre sokasodó különálló megvalósításokkal, szoftververziókkal és OOXML „változatokkal”. Ez problémák láncolatát veti fel, ugyanis minden kombináció egy kicsit másképp viselkedik különböző operációs rendszereken a Windows XP-től a Windows 8-ig, a különféle alverzióikkal, patch szintjükkel, és szervizcsomagjaikkal. Az irodai programcsomagok összeférhetetlenségét orvosolni próbáló szabadszoftver-fejlesztőknek nem elég csak az OOXML-variációkkal megküzdeniük, de tesztelniük kell a javításaikat különféle operációs rendszereken, Office verziókon, dokumentumokon és alkalmazásokon. Erre nem lenne szükség egy egységes, egyértelmű, és nyílt ISO szabvány esetében.
Táblázatkezelési bajok
A fejlesztők szerint ehhez hasonló problémák sok helyen jelentkeznek az OOXML-en belül. Továbbá, nem csak a nyílt forráskódú szoftver mozgalom szenved a váltakozó alkalmazásfajtáktól és az ISO 29500 különböző interpretációitól. Még a Microsoft is küzd nyilvánvaló hibákkal a dokumentumformátumaival.
Ezt még a laikus olvasók számára is jól példázza Italo Vignoli nemrég megjelent értekezése a blogján, a Marketing FLOSS-on. Vignoli, egy milánói újságíró, az Open/LibreOffice szakértője, és a LibreOffice otthonául szolgáló Document Foundation igazgatója.
Vignoli öt lépésben, gyakran használt táblázatkezelő-műveleteken keresztül mutatja be, hogy még a Microsoft legújabb Office-verziója, az Office 2013 sem támogatja megfelelően az Open XML Strictet, a forgalmazó összes termékéhez kikiáltott dokumentumszabványt. Egy MS Excelben készült táblázat hozzáadott adatokkal és metaadatokkal – mint például dátumok, számítások vagy képletek – az ISO-szabvány OOXML Strict formátumban mentve gondot okozhat a dokumentum későbbi megnyitása során.
Olyan problémák jelentkezhetnek, mint az adatvesztés vagy rosszul reprezentált tulajdonságok, melyek könnyen rejtve maradhatnak, mivel nem generálnak hibaüzenetet a Microsoft Office-ban. Vignoli táblázatkezelőjénél például mindössze néhány hibás dátum, netán rossz XML címke árulkodik a felhasználó számára, olyan dolgok, amik könnyen észrevétlenek maradnak, ám a közigazgatásban katasztrofális következménnyel járhatnak. Nem felejtsük el, hogy mindez ráadásul az Office 2013-ban történt, ami a Microsoft szerint a legjobb és legkiterjedtebb OOXML-támogatással rendelkezik az összes Office-verzió közül, és amely jelenleg az egyetlen elérhető szoftver, ami a szállítója szerint teljesen kompatibilis az OOXML Stricttel.
Nem szokványos hiba
A Vignoliéhoz hasonló hibák arról tanúskodnak, hogy a probléma sokkal mélyebben gyökerezik egy átlagos szoftverhibánál. 2014 januárjában Vajna Miklós magyar fejlesztő bemutatta a LibreOffice Writer legújabb verzióját, a LibreOffice Writer 4.3-at. A Writer egy komplex szövegszerkesztő számos import és export funkcióval – az MS Word megfelelője a LibreOffice csomagban. A rendszergazdák dokumentumok migrálására használják, nem csupán az import- és exportszűrők minősége miatt, de szerepet játszik a könnyedség is, amivel ezek a szűrők létrehozhatók és használhatók.
A 4.3 egyik fő fejlesztése az MS Office-ból importált fájlok alakzatainak kezelése lesz a docx importszűrő segítségével. Ez nem egyszerű feladat: Vajna bemutatta, hogy maga az Office is többféleképpen értelmezi ugyanazt a fájlt: ahol az Office 2010 egy zöld háromszöget jelenít meg, az Office 2007 egy pirosat mutat. És ez csak egyetlen példa.
A Microsoft következetlensége problémát varrt a LibreOffice fejlesztők nyakába. Mint oly sok más esetben, újra a visszafejtésre kellett hagyatkozni, végül mégis választás előtt állnak: el kell dönteniük, hogy a 2007-es vagy a 2010-es Office verzióval legyenek kompatibilisek. „Most legalább egy szinten vagyunk a Word 2010-zel.”, vallja be Vajna, hogy aztán folytassák a tucatnyi egyéb tulajdonsággal, melyek nem élik túl a mentés, exportálás, betöltés, változtatás, és újraexportálás körútját. Szarkazmussal a hangjában magyarázza, hogy mennyi időt kénytelenek a visszafejtésre fordítani a szabadszoftver-fejlesztők, csak mert a szabvány nem olyan nyílt, mint lennie kellene, és mert különböző Microsoft-termékek különbözőképpen értelmezik.
Továbbá, mivel nincs teljes és a szabványnak megfelelő megvalósítás, ami teljes körűen használja a „Strictet”, nem lehet élesben tesztelni. A Fraunhofer Intézet kutatóinak ki kellett fejleszteniük a saját OOXML Strict szoftvercsomagjukat, csak hogy tesztelhessék az OOXML- és ODF-szabványok nyújtotta lehetőségeket. Ez a probléma megnehezíti bármely OOXML-eszköz – még egy egyszerű import- vagy exportszűrő – kifejlesztését is, mivel a fejlesztőknek a Microsoft OOXML-verzióját kell alkalmazniuk; ha nem így tennék, a dokumentumok megfelelnének a szabványnak, ám használhatatlanná válnának. Hogy még rosszabb legyen: ahogy Thorsten Behrens, a Document Foundationtől elmagyarázta, „Azzal, hogy bevezette a Markup Compatibility and Extensibility (MCE) technológiát az ISO 29500-ban, a Microsoft jogosult lett arra, hogy változtatásokat eszközöljön a dokumentumformátumokon, egyszerűen a saját kiterjesztéseinek hozzáadásával – szinte korlátlanul. Ez megnehezíti bármely cég vagy szabad szoftver projekt dolgát, hogy teljesen kompatibilissé váljon.” Egy, a Microsoft blogján található írásukban Paul Lorimer és Doug Mahugh Microsoft-alkalmazottak kifejtik, mi is az az MCE: „Az ISO/IEC 29500 a Markup Compatibility and Extensibility (MCE) segítségével oldja meg ezt a problémát (formátumfrissítések). Az MCE számos megközelítés ötvözésével teszi lehetővé az innovációt újabb verziók vagy más forgalmazók számára új tartalom hozzáadásával a fájlokhoz, ugyanakkor úgy jelöli meg a tartalmat, hogy az új tartalmat nem értő alkalmazások figyelmen kívül hagyhassák vagy visszafejleszthessék azt.” Ez – „ahogy azt az ISO/IEC 29500:2008 – 3. Szakasz tartalmazza” – elsőre hasznosnak tűnik, ám a Microsoft olyan helyzetbe kerül ezáltal, amelyben a cég bármilyen frissítést, fejlesztést, változtatást, vagy bővítést hozzáadhat egy ISO-szabványhoz. Továbbá az új tartalom nem jelenik meg más szállítók régebbi, ISO 29500-kompatibilis szoftverein. Csak a frissen hozzáadott bővítésekről, funkciókról, azok természetéről tudó szoftver fogja a készítője szándékának megfelelően megjeleníteni a dokumentumot.
Skövdei Egyetem: A folytonosság hiánya
Egy harmadik példa: a svédországi Skövdei Egyetem egyik informatikaprofesszora hasonló tapasztalatokra tett szert az MS Office OOXML-használatával kapcsolatban. „Nem működik.”, mondja Björn Lundell, akinek a csapata az egyetem Információtechnológiai Tanszékén irodai programcsomagok szabványait és kompatibilitását kutatja. Semmilyen más alkalmazás nem képes hibátlanul betölteni minden különböző OOXML-verziót, mondja Lundell, bár a LibreOffice határozottan jól teljesít.
A LibreOffice nem tud megfelelően dolgozni a Microsoft docx-fájlokkal, különösen a körutazást megjártak esetében, mondja Lundell, mint ahogy még arra sincs reális esély, hogy a Microsoft régebbi verziói képesek erre. „A jelenleg folyó kutatásunkban, melynek tárgya az interoperabilitás (hiánya), az MS szoftverekkel létrehozott docx fájlok hosszú életét is vizsgáljuk.”, magyarázza. A skövdei csapatot az érdekli, amit ők „belső együttműködésnek” hívnak, a szállító szoftvereinek különböző verziói között. Azt vizsgálják, milyen mértékben képesek az újabb verziójú MS szoftverek olvasni, szerkeszteni, és újra elmenteni a régebbi verziókkal létrehozott dokumentumokat.
A mindössze négy éves fájlok megnyitásának problémája
„Nem vitás, hogy számos probléma akad a csupán négy éve létrehozott fájlok értelmezésével”, mondja Lundell. „Ezt tovább bonyolítja, persze az OOXML-szabvány Strict és Transitional verzióinak a problémaköre, és az általuk okozott kavarodás. Ha egy felhasználó létrehozott egy fájlt MS Office 2007-ben és Transitional docx formátumként mentette, azt másoknak meg kellene tudniuk nyitni Office 2013-ban, újra elmenteni Strict docx-ként, és végül Office 2010-ben olvasni”, mondja. „De a valódi végkifejlet meghökkentő.”
Egy ilyen körútsorozat egyáltalán nem szokatlan: „Tekintettel arra, hogy minden új fájlt (az ISO/IEC 29500 szerint) OOXML Strictben kellene elmenteni, ez a forgatókönyv számos szervezetet érinthet napi szinten”, mondja Lundell. A kutatás eredményei még nem véglegesek, de tény, hogy a Microsoft programjai történelmi okokból egy ISO-szabvány különböző verzióit olvassák és írják. Ez egyre súlyosbodó problémát jelent a közigazgatási számítógépeken.
A közintézmények félrevezetése
Lundell szerint ez a helyzet roppant veszélyes. „Tudom, hogy (Svédországban) hatalmas közigazgatási intézmények fontolgatják valamennyi fájljuk docx-re való migrálását, mert az a (téves) elképzelésük, hogy léteznek nyílt forráskódú alternatívák, melyek megfelelő interoperabilitást biztosítanak. Mi tisztában vagyunk vele, hogy korántsem ez a helyzet. A valóság az, hogy a formátum olyannyira silány, hogy még a Microsoft sem képes biztosítani a saját szoftverének különböző verziói közötti együttműködést.” Lundell úgy véli, a mostaninál sokkal több kommunikációra és egyeztetésre van szükség. „Elég csak a szállítótól való függőséget említeni, ahogy az az MS Office különböző verzióiban kiütközik; nyilvánvaló, hogy az OOXML nem állja ki a próbát”, mondja.
Lundell tanulmánya nem az egyedüli bizonyíték arra, hogy az OOXML több ponton sem felel meg az ipari szabványokkal szemben támasztott elvárásoknak. A Microsoft honlapján elérhető egy „OOXML Strict Converter for Office 2010” nevű termék. A cég marketingje és az ISO-bizottságnak tett ígéretei szerint erre a konverterre nem lenne szükség.
Daniel Melin, a Kammarkollegiet beszerzési vezetője – egy pénzügyi és jogi ügyekkel foglalkozó svéd közintézmény – azt kérdezi: „Miért kell konverter, ha a támogatásnak beépítettnek kellene lennie?” A szállító a termék weboldalán megmagyarázza: „Az OOXML Strict Converter for Office 2010 lehetővé teszi az Office 2013-mal készült dokumentumok megnyitását az Office 2010-ben. Hitelesen megőrzi a dokumentum jellegét. Amennyiben változtatásokra és mentésre kerül sor, a dokumentumot Transitional formátumban menti el.” Vagyis: „Az MS Office 2010 felhasználója meg tudja nyitni az Office 2013 által generált OOXML Strict dokumentumot, de ezután az Office 2010 OOXML Transitional formátumban menti a fájlt.
ECMA, Transitional és Strict
Ennek a különös viselkedésnek a magyarázata az ECMA/ISO/IEC dokumentumszabványok történetében rejlik. Thorsten Behrens a Document Foundation-től elmagyarázza, hogy az OOXML gyakorlatilag három szabványt vagy „változatot” tartalmaz: az első az ECMA-verzió (MS Office 2007 által használt, ECMA International által hitelesített). Aztán ott van az OOXML Transitional, ami viszonylag közel áll az ECMA-verzióhoz, és ami a mai napig az összes későbbi verzió alapértelmezett formátuma. És végül ott az OOXML Strict.
Tíz éve a Microsoft felismerte, hogy az ODF jó úton halad afelé, hogy általánosan elfogadott szabvánnyá váljon, és elkezdte szorgalmazni a saját XML-alapú dokumentumformátumát. Rövid időn belül a szállítónak sikerült XML-verziókat definiálnia a bináris dokumentumformátumaiból, amiket az ECMA International elfogadott szabványnak. Azonban ugyanezt a kérvényt az ISO-bizottság elutasította, mert túl sok bináris, szállítóspecifikus, Windows- és Office-specifikus függőséget tartalmazott. Az ISO-csoport meg volt róla győződve, hogy a szállítón kívül senki más nem lesz képes megvalósítani.
Kompromisszumra volt szükség. „Végül az ISO-csoport a jövőbeli szabványt látta az OOXML Strictben”, mondja Behrens. Ez a kompromisszum tette lehetővé, hogy az ISO/IEC 29500 legalább a Ballot Resolution Meeting (BRM) stádiumon átjusson.
Korlátozott ideig az ISO engedélyezett egy másik szabvány is, az ISO/IEC 29500 Transitionalt. „Mind a 29500 Transitional, mind a 29500 Strict teljes ISO-szabványok”, magyarázza Behrens. Csak arról van szó, hogy az ISO munkacsoport nem kedveli annyira a Transitionalt – de a BRM-fázisban kötött kompromisszum az volt, hogy mindkét „változat” szerepeljen az ISO-szabványban. A 29500 Strict és a 29500 Transitional közti különbségek a 29500 4. részben vannak meghatározva (Transitional Migration Features), ami 1464 oldalnyi terjedelmű.
| „Ha egy felhasználó létrehozott egy fájlt MS Office 2007-ben és Transitional docx formátumként mentette, azt másoknak meg kellene tudniuk nyitni Office 2013-ban, újra elmenteni Strict docx-ként, és végül Office 2010-ben olvasni”, mondja. „De a valódi végkifejlet meghökkentő.”
– Björn Lundell, a svéd Skövdei Egyetem informatikusprofesszora |
A szabványosítási folyamat története tömören itt található. A valaha egységesnek szánt szabványt jelenleg is három különböző formátum alkotja: az ECMA, amit az Office 2007 használ; a Transitional, amit pl. az Office 2010; és a Strict, amit a Microsoft állítása szerint teljesen támogat az MS Office 2013. A legtöbb fejlesztő egyetért abban, hogy nincs olyan elérhető termék, ami megfelelne az OOXML Strict ISO-szabványának, és az Italo Vignoliéhoz, vagy Björn Lundell csoportjáéhoz hasonló tapasztalatok a jelek szerint azt bizonyítják, hogy a forgalmazó állítása nem fedi a valóságot. Továbbá, olaj a tűzre, hogy nem áll rendelkezésre olyan tesztkörnyezet, vagy tesztleírás, ami bizonyíthatná, hogy bármely szoftvertermék, vagy általa készített dokumentum teljesen kompatibilis az OOXML-specifikáció összes tulajdonságával. Svante Schubert szerint ez nem valószínű. Az, hogy az OOXML specifikáció már most annyira összetett, lehetetlenné teszi egy működőképes tesztsorozat felállítását.
A sajtó figyelemmel kísérte a folyamatot, és számos beszámoló látott napvilágot. Olyan írások, mint
- Wikipedia : Complaints about the national bodies process
- The Inquirer: Norway ISO members walk out over OOXML
- Arstechnica: Norwegian standards body implodes over OOXML controversy
feltételezik, hogy a Microsoft megpróbált nyomást gyakorolni a bizottságokra, vagy direkt módon, vagy a kormányokon keresztül. Norvégiában az OOXML szabványosítási folyamattal foglalkozó nemzeti bizottság 23 szakértője közül 13-an be is adták lemondásukat. Az indok pedig: „a kereskedelmi érdek egyértelműen… a társadalom érdeke elé helyeződött”.
A brit kabinetiroda az ODF mellett
2014 elején az egyesült királyság kabinetiroda az ODF-et szavazta meg preferált szabványának. A döntést heves vita övezte, mindkét oldal érvek százait sorakoztatta fel. A sok kiváló fejlesztő között, akik reagáltak az ügyre, ott volt Michael Meeks, Simon Phipps az Open Source Initiative oszlopos tagja, és Jeremy Allison a Samba projekttől.
Vint Cerf, a Google alelnökének nyilatkozata azt sugallta, hogy a Google is az ODF-re támaszkodik. A Microsoft is felszólalt a vitában, tagadta a problémákat, azt állította, hogy az OOXML a legelterjedtebb XML-dokumentumformátum, és kijelentette, hogy a felhasználók egyáltalán nincsenek rákényszerítve Microsoft-szoftver megvásárlására: „Számtalan eszköz (programok, alkalmazások, szolgáltatások) áll rendelkezésre, eltérő árakon.”
Angol vagy görög?
Michael Meeks egy hosszú bejegyzésben vázolja az eltérő irodai programcsomag-formátumokkal kapcsolatban felmerülő rengeteg problémát és a mögöttük rejlő okokat. „Látva, hogyan lehetséges egy szállítónak, hogy az ECMA/ISO gyorsított eljárás használatával tulajdonképpen a saját megvalósítása minden részletét szabványosíttassa, érdekes összehasonlítani ezt az ODF-fel”, írja, hozzátéve, hogy az ODF számos eszközön és platformon használható, nem csupán Windowson. Az OOXML leírása közel tízszer akkora terjedelmű, mint az ODF-é (7000 vs 850 oldal), ráadásul Microsoft binárisoktól függ.
Meeks szerint az OOXML-nek van még egy kirívó tulajdonsága: az ODF-hez képest sokkal nehezebben érthető, illetve programozható. Meeks az ógöröghöz hasonlítja az OOXML-t: bőségesen toldalékolt, roppant összetett nyelv, „ami gyakran nagybetűvel íródik, szóközök nélkül.”
„Az ODF pedig a dokumentumszabványok »angoljaként« szerepel a párhuzamban: sok eltérő nyelv képezi alapját és forrását, lényegesen egyszerűbb az elsajátítása és a használatával történő kommunikáció is.”
Eltérő szabványok, eltérő célok
Elemzők, köztük a Fraunhofer Intézet munkatársai egyetértenek abban, hogy a Microsoft célja a bináris formátumainak átörökítése volt XML-be, ami segít a vállalatnak megőrizni az irodai programcsomagjai kereskedelmi sikerét egy olyan világban, ahol egyre több közigazgatási szervezet ismerte fel egy nyílt forráskódú szabvány szükségességét. Az „ISO által szabványosított” címke fontos marketingeszköze lett a szoftvercégnek.
Másrészről viszont az ODF kifejlesztésének oka és célja is teljesen más volt. Az egyszerűségének oka a szabvány indíttatásában rejlik: a Document Foundation Simon Phippshez hasonló tagjai számára a fő motiváció az volt, hogy minél könnyebben érthető, és hatékony együttműködésre képes formátumot alkossanak meg. „A céljaink között volt az ODF-fel egy olyan dokumentumformátum létrehozása, ami lehetővé teszi a lakosság számára a hivatalokkal való kapcsolattartást anélkül, hogy zárt forrású szoftverek akadályt gördítsenek eléjük”, mondja.
Svante Schubert rámutat, hogy az ODF sokkal széleskörűbb támogatottsággal rendelkezik, mint az OOXML. Az ODF még a modern webes dokumentummegvalósítások által is támogatott (melyek fiatalok ugyan, és egyelőre többé-kevésbé kísérleti jellegűek). Az ODF-et különböző szabad és kereskedelmi irodai termékek szállítói támogatják, olyanok, mint az IBM (Lotus), a Google, a Microsoft, a Corel és az Adobe, és sok más szabad és nyílt forráskódú alkalmazás, különböző programok és felületek, köztük az AbiWord, Scribus, Inkscape, KOffice, Okular és NeoOffice. „Miközben a Microsoft kijelentette, hogy támogatja az ODF-et, van bármilyen indok az összetettségre való törekvésre és a költségek növelésére (a brit kormány esetében) két irodai szabvány egyenlő támogatásában? Mi más oka lehet – a szállítói függés fenntartásán kívül – a Microsoftnak, hogy ne támogassa az ODF-et?” – teszi fel a kérdést Schubert.
A fejlesztők szerint ez nem jelenthet nagy munkát: Mikor a Microsoft az első ECMA International szabványt vezette be 2007-ben, a szakértőket meglepte, hogy a cég milyen gyorsan képes volt végrehajtani a több ezer oldalon át gyűrűző szabványosítást. És mivel a cég megvalósította az ODF-et az összes Office-termékében 2007 óta, a teljes és szabványkompatibilis ODF-támogatás már nem igényelhet sok munkát, véli Schubert.
Az OOXML-verziók elkerülhetetlen hibákat okoznak
A problémákra, melyek abból fakadnak, hogy csak egyetlen szállító létezik – aki ráadásul inkompatibilis szoftver- és szabványverziókat szolgáltat – az egyedüli megoldást az jelentené, ha minden számítógépre megvásárolnák a legújabb verziókat a Microsofttól, és a teljes digitális fájlarchívumot végigellenőriznék, hogy biztosítsák a kompatibilitást a régi fájlokkal. Ez se nem járható út, se nem fenntartható szemlélet, állítják egybehangzóan a fejlesztők és informatikusok. Rengeteg időt és munkaórát venne igénybe, és az eredmény bizonytalan marad, amennyiben a szállító ismét úgy dönt, hogy változtat a formátumon vagy a stratégián.
A Meekshez, Schuberthez, és Behrenshez hasonló fejlesztők meggyőződése szerint nem valószínű, hogy egy olyan cég, mint a Microsoft pénzt fektetne egy elavult termékbe, amilyen az Office 2007 is, csak hogy a régi fájlformátumok működését biztosítsa.
A szabad szoftverek támogatói ennél is messzebbre mennek, attól tartva, hogy a szállító az összeférhetetlenséget arra használja, hogy nyomást gyakoroljon azokra a felhasználókra, akik nem akarnak frissíteni. Mivel semmilyen más termék nem kompatibilis teljesen az OOXML különböző verzióival, és mivel ez súlyos problémákhoz vezet a körutak során, aki ezt az utat választja, az a Microsofthoz láncolja magát – fennakad a szállító hálóján.
ODF – az „egyenes út előre”
A fejlesztők és kutatók viszont a második, széles körben használt szabványt (az ISO/IEC 26300-at) részesítik előnyben, amit sok termék alkalmaz. Björn Lundell, a Skövdei Egyetem munkatársa, összhangban más kutatásokkal bebizonyította, hogy sokkal több szoftver és eszköz támogatja az ODF-et, mint az OOXML-t. Valójában kizárólag a Microsoft biztosít folyamatosan eszközöket a kedvenc szabványához.
A szabad szoftveres közösség az ODF-et támogatja. Italo Vignoli felhívja a figyelmet a LibreOffice levelezőlistáján szereplő érvekre: „Az ODF folyamatosságot képvisel. Az ODF egyenesen előre tart, és rendszeresen karbantartja az OASIS. Létezik egy ODF 1.0, ami ISO-szabvány, és az ODF 1.2 (ami visszamenőleg kompatibilis az ODF 1.0-val), ez utóbbi szabványosítása pedig folyamatban van. A szabvány meghatározása természeténél fogva lassan változik. Ez az oka, hogy a LibreOffice az ODF 1.0-val és az ODF 1.2-vel egyaránt kompatibilis.
Az archiválási szakértők is nyílt forráskódú szoftverekben és nem jogvédett, hiánytalanul dokumentált szabványokban látják a megoldást a digitális dokumentumok folyamatos fenntarthatóságára. „A digitális állományok mindig túlélik a szoftvereket és a szállítókat”, jegyzi meg Lundell és kollégája, Jonas Gamalielsson egy egyetemi tanulmányban. A TAM-Arkiv nevű svéd archiválási szervezet álláspontja még radikálisabb: „Sose használj szállítótól függő formátumot hosszú távú tárolásra, ha ez megoldható, ezek ugyanis gyakran instabilok, szervezetlenek, és ki vannak szolgáltatva különféle szállítók üzleti stratégiáinak.”
Másrészről a Microsoft OOXML-t sosem valósította meg egy szállító sem az ISO-szabvány kikötéseinek megfelelően, és nincs is az ECMA International folyamatos ellenőrzése alatt (mert ez a szervezet nem koncentrál annyira a dokumentumszabványokra, mint az OASIS). Sajnos a piacon több OOXML-dokumentum fordul elő, mint ODF.
Hosszú távú szállítófüggetlen támogatás
Patrick Durusau, az ODF Technikai Bizottságának társelnöke a nem szállítófüggetlen szabványok használatának veszélyeit hangsúlyozza. „Egy további érv, hogy amennyiben sok alkalmazás támogatja ugyanazt a formátumot, a formátum alkalmassá válik megőrzési/tárolási célokra. Ha egy vagy több szállító úgy dönt, megszünteti egy régebbi formátum támogatását, nem probléma, mert még mindig vannak lehetőségeid a korábbi formátumot illetően. Ha a Microsoft szüntet meg bármilyen támogatás a formátumával kapcsolatban, egyszerűen nem érheted el többé azt a tulajdonságot. Ez súlyos érv, különösen kormányzatok esetében, mivel ott rengeteg a megőrzendő dokumentum, és egyre több lesz a jövőben.”
Az ODF a több teljes megvalósítással választást biztosít a felhasználók számára, és biztonságot a jövőbeli támogatást illetően. A nemrég kifejlesztett rengeteg import/exportszűrő az Open/LibreOffice-ban szintén alátámasztja Durusau állítását.
Az ODF Szövetség szerint a Microsoft stratégiájában megtévesztés fedezhető fel. „Az, hogy a cég nem valósítja meg az OOXML Strictet, miközben magánúton bővíti a Transitionalt, azt jelenti, hogy nem veszik figyelembe az ISO által az OOXML elfogadásához elvárt fejlesztéseket” Az ODF Szövetség azt állítja, hogy 2010-ben az OOXML Ballot Resolution Meeting szervezője kijelentette, hogy „az egész OOXML-projekt bukásra van ítélve.”
| „Az, hogy a cég nem valósítja meg az OOXML Strictet, miközben magánúton bővíti a Transitionalt, azt jelenti, hogy nem veszik figyelembe az ISO által az OOXML elfogadásához elvárt fejlesztéseket.”– Az ODF Szövetség |
Közös munka: közösségi indíttatás
Egyre több közigazgatási szervezet vált át szabad és nyílt forráskódú szoftverekre, és tapasztalja meg az OSS fejlesztési modell előnyeit. A folyamat egyértelműen kimutatható az Európai Bizottság Open Source Observatory and Repository weboldala által elkönyvelt, egyre gyarapodó példákból:
- Franciaország: A Csendőrség és kormányzati minisztériumok;
- Spanyolország: Extremadura autonóm régió, a Kanári-szigetek, és Zaragoza városa;
- Svájc: A Szövetségi Bíróság és a Szövetségi IT-irányítási egység;
- Németország: München, Lipcse, valamit Jéna városok
Európa-szerte az önkormányzatok bizonyítják, hogyan takarékoskodhatnak az adófizetők pénzével a Microsoft-licencek elutasításával és Apache OpenOffice vagy LibreOffice használatával.
Viszont azzal, hogy kiszabadulnak az irodai programcsomagok csapdáiból, legyenek bárhol, a közigazgatási szervek szembe találják magukat a szabad és nyílt forráskódú irodai csomagok és a mindenütt jelenlevő jogvédett alternatíva közti összeférhetetlenségekkel. Azáltal, hogy az informatikai piacot egyetlen jogvédett irodai programcsomag uralja, és nincs egy egységes dokumentumformátumra való törekvés, a közigazgatás nem részesül a szabványosítás előnyeiből.
Erre világított rá Tineke Egyedi, a holland Delfti Műszaki Egyetem szabványügyi szakértője, egy 2012-es, dokumentumszabványok rivalizálásáról szóló publikációjában. Egyedi kiemeli, hogy az OOXML érkezése megerősíti a szállítói függést, és növeli a kormányzatok költségeit, akik rá vannak kényszerítve mindkét szabvány támogatására.
Julian Conde pedig, aki a szabad szoftver projekt vezetője Andalúzia spanyol autonóm régió, közigazgatásában, hangsúlyozza, hogy nem a dokumentumszabványok jelentik az egyedüli problémát. Több tényező nehezíti a dokumentumok egyik operációs rendszerről másikra való átvitelét, például a betűméretek, és egyes betűtípusok, melyek nem érhetők el Linuxon. De ahogy mondja: „A betűtípus kérdése nem közvetlenül az OOXML vagy az ODF által okozott probléma, hanem ismét egy példa arra, mennyire fontos lenne egy egységes és átlátható szabvány. A margón átnyúló szövegeknél információ és adatok vesznek el.” Andalúziában az informatikai osztályok megkísérelték korábban az OOXML szabad szoftveres alkalmazását, és bár „a LibreOffice legújabb verziói jelentősen fejlődtek”, Conde nem volt elégedett. De, mivel a nemzeti interoperabilitási és szabványügyi szabályozás csak az ODF-et és az OOXML Strictet engedélyezi, a Microsoft termékei nem használhatók az önkormányzatokban – elméletileg. „Amennyire tudom, nincs olyan irodai programcsomag, ami valóban OOXML-Strict kompatibilis”, erősíti meg Conde. „Így a szabályaink értelmében nem szabadna OOXML-t használnunk.”
Fizetés előre
Több európai ország közigazgatása hangot adott az irodai programcsomagok összeférhetetlenségével való küzdelmének. Egy példa a németországi Freiburg, ahol 2012-ben megszakították a nyílt forráskódú irodai csomagra való átváltást. Mindössze egy évvel korábban a város nyílt forráskódú szabványokkal foglalkozó projektvezetője az IT-részlegnél elmagyarázta, hogy „két évtizednyi monokultúra mellett az irodai alkalmazások terén nincs interoperabilitási nyomás.”
Az európai közigazgatási szervek szintén hiába folyamodtak az Európai Unió intézményeihez. „Még mindig nincs meg egy „nagy nevű” EU-intézmény súlya ahhoz, hogy tényleg kirázza a közszférát a konzervatív nézőpontjából”, mondta Mark Wright, a bristoli városi tanács tagja, 2011-ben.
Ugyanabban az évben München városa levelet küldött az Európai Bizottságnak, melyben segítséget kért a dokumentumok interoperabilitásával vívott küzdelmében. A levélben Christian Ude polgármester tiltakozott az Informatikai Tárcaközi Bizottság (Inter-Institutional Committee for Informatics) javaslata ellen, miszerint az EU-intézmények továbbra is a nem egységes OOXML-szabványt használják. Ez, írta, meggátolja a közhivatalok együttműködését.
München jó példája a megoldásra törekvő közigazgatási rendszereknek. Amint azt egy 2013-as OSOR-tanulmány leírja, München Limux-projektjében szerepelt egy kiterjedt LibreOffice-ra való migráció, és ami a WollMux kifejlesztéséhez vezetett – egy nyílt forráskódú eszköz űrlapok és dokumentumsablonok kezelésére. A név bajor eredetű, az „Eierlegende Wollmux”-ra, egy kitalált háziállatra utal, ami húst, gyapjút, tojást, és tejet ad. A párhuzam adott, a WollMux rendeltetése, hogy ellásson minden feladatot az irodai dokumentumautomatizáció hatalmas területén. A WollMux lehetővé teszi az alkalmazottaknak a sablon kiválasztását az ügyfelekkel való munkájukhoz, majd automatikusan kitölti azokat központilag tárolt adatokkal, kifogástalan dokumentumokat produkálva percek alatt.
München előrelátó befektetése lehetőséget ad a többi közigazgatásnak az előrelépésre a dokumentum-interoperabilitás orvoslásának hosszú útján. Az okos bajor főváros részt vesz egy még átfogóbb folyamatban is, a dokumentumszabványok rejtvényének megoldására törekedve. A város egyike annak az öt közigazgatási egységnek, amelyek a német OSBA-val (Open Source Business Alliance) dolgoznak, a nyílt forráskódú üzleti szolgáltatók szervezetével. A város az OSBA irodai csomagok összeférhetetlenségével foglalkozó munkacsoport tagjaként finanszírozza a LibreOffice és az Apache OpenOffice terjesztését.
Az OSBA által szervezett első, 2012-es pályázat az Open/LibreOffice OOXML import/exportszűrőjének szükséges fejlesztéseire irányult. Ezt az első kört közigazgatási szervezetek egy csoportja finanszírozta, köztük a Svájci Szövetségi Bíróság és a francia Kulturális és Kommunikációs Minisztérium.
Hat használati eset a fejlődésért közösségi finanszírozássalAz idei második tevékenységi körre az OSB munkacsoport – München, Lipcse, Jéna, valamint a Svájci Szövetségi Bíróság és a svájci Szövetségi IT-irányítási egység (FITSU) finanszírozásával – választott hat prioritást élvező területet. Az egyik legfőbb fejlesztés a nyílt forráskódú és jogvédett irodai programcsomagok közötti változáskövetést célozza meg. Az indítványozó közigazgatások fejleszteni kívánják a változáskövetés részletességét, és azt szeretnék, ha az Open Document Format ISO-szabvány részét képezné. Ez elhárítaná az akadályokat a Microsoft útjából, hogy az ODF-változáskövetést alkalmazza az irodai csomagjában, magyarázza Svante Schubert, aki részt vett a pályázatkiírásban. „Az MS Office csomag jelenleg megfosztja a változáskövetés információitól az ODF-dokumentumokat, ellehetetlenítve az ODF-dokumentumok cseréjét azok között a felhasználók között, akik számára nélkülözhetetlen (a változáskövetés), például jogi osztályok.” Az új pályázatkiírás, hivatalos nevén A LibreOffice/Apache OpenOffice fő területi fejlesztései, öt további használati esetet foglal magába:
A projektek jelenleg nyílt közbeszerzési eljárás alatt állnak, a szerződések aláírása 2014 májusában esedékes. A költségeket a munkacsoport tagjai állják közösségi finanszírozású rendszerben, amely nyitott más közigazgatások felé is a csatlakozásra. A tervek szerint mind a hat projekt elkészül 2014 végéig. Minden kód licence nyílt forrású lesz; az eredmények elérhetőek lesznek bármely közigazgatás és a szabad és nyílt forráskódú irodai programcsomagok egyéb felhasználói számára. |
Konklúzió
Az OOXML-szabvány problémákat okoz a közigazgatásban. Egy ISO-szabványhoz képest meglepő hiányosságai vannak: Semmilyen termék nem kompatibilis az egyetlen elfogadható szabványverzióval (a legújabb ‘Strict’), és a Microsoft termékeinek sincs alternatívája. Az utóbbi az évek során a szabvány különböző fajtáit használta, ezzel problémát okozva az archiválás és dokumentumcsere terén. Ezek a változatok jelen vannak mindenütt, lehetetlenné téve a „Strict” szabvány használatát a Microsoft Office régebbi verzióival – olyan verziókkal, amelyek forgalmazását a szállító már megszüntette, így sosem fogják érteni az OOXML Strictet.
Ám a termékek naprakész verziói, sőt, még a legújabb ISO-szabvány is súlyos kérdéseket vetnek fel. Elsősorban a versenytársak és a szabadszoftver-fejlesztők számára okoznak problémát. Ahhoz képest, hogy egy ISO-szabvány célja pont az lenne, hogy a riválisok számára hozzáférhetővé tegyen egy szabványosított technológiát és ezáltal piacot biztosítson, az ISO 29500 számos meglepő kiskaput és csapdát rejt magában. Vannak MCE-kiterjesztések, melyeket csak a Microsoft ismer, és különös tárolási elemek, amelyekre az ad választ, hogy a Microsoft kénytelen volt a dokumentumformátumát egy nyílt XML-stílusú formátumhoz igazítani, hogy elnyerje az áhított ISO-minősítést, hónapokkal azután, hogy az ODF ISO-szabvány lett.
Ugyanakkor jelen van egy szabad szoftveres és üzleti szintű fejlesztőkből álló aktív tábor. Az említett közösség különböző ipari, politikai, valamint civil szervezet támogatását élvezi; mindegyiküknek rengeteg idejét emészti fel a programozás, hogy Microsoft-kompatibilissé tegyék az alkalmazásaikat. A munkájuk roppant időigényes és fárasztó, rengeteg próbálgatás, pepecselés szükséges, az eredményeiket tesztelniük kell a Microsoft Office különböző verzióiban. És a legvégén ezek a szűrők még mindig csak a Microsoft Office „X” verziójával lesznek kompatibilisek, nem a teljes OOXML-szabvánnyal.
Egyre több európai önkormányzat számolt be a müncheni helyzethez hasonló tapasztalatokról. Az OSBA munkacsoport sikere pedig egyértelműen bizonyítja, milyen hatásos lehet egy közösségi finanszírozású együttműködésen alapuló megközelítés – amennyiben vannak szabad és nyílt forráskódú szabványok, amelyek nem egyetlen domináns szállító ellenőrzése alatt állnak.
Eltekintve az összegektől, amiket azzal spóroltak meg, hogy nem kellett újra feltalálni a kereket, sem jogvédett szoftverek licenceiért fizetni, vannak sokkal alapvetőbb és lényegesebb előnyök, amik felbecsülhetetlenek. „A digitális állományok mindig túlélik a szoftvereket és a szállítókat”, áll a fent taglalt svéd egyetemi tanulmányban. „Sose használj szállítótól függő formátumot hosszú távú tárolásra, ha ez megoldható, ezek ugyanis gyakran instabilok, szervezetlenek, és ki vannak szolgáltatva különféle szállítók üzleti stratégiáinak.”
Ezt a cikket Markus Feilner írta az Európai Bizottság Open Source Observatory and Repository, OSOR weboldala számára. A magyar fordítást Pék Júlia készítette a libreoffice.hu számára.
Egész jó cikk, csak két dolog nem tetszik benne.
1. Az elején többször is le lett írva ugyanaz, és ettől túl hosszú lett.
2. A cikkből nem derül ki, hogy mit értett Björn Lundell azon, hogy „De a valódi végkifejlet meghökkentő.”