szszi

szsz






Gondolatok az OOXML kapcsán


Történelmi áttekintés
Problémák az OOXML-el
  Szabványsértések
  Kidolgozatlanság
  Bitmaszkok
  Zárt szoftverekre hivatkozás
  Méretek
  Jogi problémák
  Zárt fejlesztési eljárás
A szavazás érdekességei
A szavazatról

Történelmi áttekintés
Különböző szervezetek, köztük az EU, itt nem részletezett (főleg archiválási és interoperabilitási) okokból igénylik szabványos dokumentumformátumok létét. i Az OpenOffice.org-ból született az Open Document Format, továbbiakban ODF, vagy ISO 26300. Az OASIS ii nevű, XML és SGML alapú formátumok kidolgozásában évtizedes gyakorlattal bíró, több iparági szereplő (IBM, SUN, SAP) által alapított, nyílt döntéshozatallal működő szervezet nyújtotta be az ISO/IEC JTC 34-es munkacsoportjához. 2006 decemberében fogadta be az ISO, ISO/IEC 26300:2006 néven. iii

Azóta az OpenOffice.org, és annak kereskedelmi változata, a StarOffice mellett több cég is bejelentette, hogy alkalmazni fogja (Corel, IBM), vagy már alkalmazza (KOffice, Google).

A Microsoft más utat választott WordML formátumának szabványosítására. Nem közvetlenül az ISO-hoz fordult, hanem az Ecma-hoz. Az ECMA korábban magnókazetták szabványosításával foglalkozott, de viszonylag laza szervezete lehetővé teszi, hogy úgynevezett gyorsított (fast track) eljárással lehessen szabványokat átverni az ISO-n. iv Az ECMA 2006 decemberében fogadta el, ECMA 376 néven az OOXML-t, és rögtön be is küldte az ISO-hoz gyorsított eljárásra. Az eljárás első fázisa egy harminc napos időszak, amikor ellentmondásokat keresnek a szabványban. Szokatlanul sok, 20 nemzeti testület küldött véleményt. v

Egy támogató vélemény mellé érkezett nyolc „equivocal” (kétértelmű), hat elutasító és öt tartózkodó. Ennek ellenére az OOXML továbbkerült az öt hónapos szavazásra, amikor a nemzeti testületek alkotnak véleményt.


Problémák az OOXML-el

Szabványsértések

Gergely-naptár (ISO 8601)

Az MS OOXML szerint 1900 szökőév. A széles körben elfogadott és használt Gergely-naptár szerint nem. Erre azért van szükség, hogy egy régi Microsoft Excel hibát tudjanak kezelni – de erre lenne más megoldás is, és az OOXML máshol használ is jobb megoldást.

Hasonlóan értelmetlen az, hogy az OOXML szerint évszámok nem lehetnek 1900-nál kisebbek.

Ország- és nyelvkódok (ISO 639)

Az OOXML az ISO által szabványosított kódok helyett egy saját, numerikus listát tartalmaz. Ennek gyökere nyilván a Microsoft régi, bináris, zárt fájlformátumaiban kereshető, de a szabványosítás éppen arról szólna, hogy ilyen légből kapott listák ne legyenek.

Konkurens, nem szabványos formátumok használata

Az OOXML képek ábrázolására a Windows Metafile formátumot tartalmazza, ami szabványosítatlan, zárt formátum. Használhatná ehelyett a W3C SVG vagy az ISO/IEC 8632 CGM formátumokat. Vektoros ábrákhoz a DrawingML belső formátumot használja az SVG helyett. Érdekes tény, hogy ez a két formátum már megvitatásra került a W3C előtt, és akkor az a döntés született, hogy az SVG lesz a szabvány. Hasonlóan figyelmen kívül hagyja a W3C MathML és SMIL szabványait is.

A leggyakoribb érv e devianciák mellett az, hogy ezek a formátumok nem tudnak mindent, amire a Microsoft alkalmazások képesek. Erre a helyes válasz az, hogy igen, ilyen van, és van rá korrekt eljárás, például amit az ODF alkalmaz az SVG-vel kapcsolatban: vannak olyan funkciók, amik nincsenek meg az SVG-ben, de az ODF-ben igen (3D rajzok), és olyanok is, amik az SVG-ben igen, de az ODF-ben nem (bézier-görbék), de ami közös, az az SVG meghatározásait használva szerepel az ODF-ben.

A papírméretekre is saját listát definiál, ami egyfelől az ISO 261 figyelmen kívül hagyása, másfelől fölösleges, az ODF például a papírméretet milliméterben tárolja, és a szabványos papírméret-kezelést az alkalmazásra bízza.

Tágabb értelemben az egész OOXML ütközik az ODF-el, hiszen az ODF már ISO szabvány. A helyes eljárás itt is az lett volna, hogy az OOXML helyett kiegészítéseket dolgoznak ki az ODF-hez. Sajnos az OOXML kidolgozói nem szabványosításra és korrekt technikai megoldásokra törekednek.

Titkosítás

Számtalan, nemzetközi szervezetek, egyetemek által vizsgált, ellenőrzött és ismert működésű titkosítási eljárás van. Ennek ellenére a Microsoft saját, senki által nem ellenőrzött, ismeretlen hibákkal felvértezett algoritmust vezet be. Ez nem csak a dokumentumok biztonsága miatt gond, de ha ez az algoritmus az OOXML-el együtt szabványosításra kerül, akkor sokan hihetik, hogy átesett ugyanazon az alapos szűrésen, mint az MD5, ISO 10118-3 vagy SHA512. Az emiatt felelőtlenül használt algoritmus más területeket is veszélybe sodorhat.


Kidolgozatlanság

Az OOXML szabványtervezetet elég hirtelen „dobták” össze. Ez abból is látszik, hogy bár hatezer (6000) oldal (az ODF 722), és rövid idő volt a vizsgálatra (30 nap), több egyszerű, figyelmetlenségből eredő hibát is találtak benne. Ezek aránylag egyszerűen javíthatóak, csak ehhez el kellene felejteni a gyorsított eljárást. Pár példa:



Légből kapott mértékegységek: EMU (6000 EMUs/cm), twip (egyhuszad pont)



A w:sz elem, ami különböző objektumok szélességét adja meg, az objektumtól függően hol félpontban, hol egész pontban, nyolcadpontban, szöveges objektumként, pixelben, százalékban értelmezendő.



Számtalan stílust definiál, de ezek jó részének adatai hiányosak. Míg a basicThinLine elég alaposan le van írva, a scaredCat vagy a babyRattle nem. Ezeket egységesen implementálni nem lehet.



A hexadecimális számok méretének meghatározása zavaros. A „digit”, számjegy kifejezést hol 4, hol nyolc bitre használja, ami egyértelműen a klasszikus korrektúra hiánya.



Nem XML-konform neveket alkalmaznak. Az XML, definíció szerint, olvasható kell legyen, és a tömörség nem feltétel. Ezzel szemben a programozók szeretik, ha a gyakran használt nevek nem túl hosszúak, ezért rövidítik azokat. Az OOXML teljesen ötletszerű, olvashatóságot nehezítő összevonásokat és rövidítéseket használ.



A százalékok jelölésére 4 különböző mód szerepel a szabványban, és némelyik kifejezetten nehezen kezelhető XML eszközökkel, mint például a „pct15”, ami 15%-ot jelent.



Alkalmazások opciói szerepelnek a dokumentumszabványban, ahol semmi keresnivalójuk, például hogy a \-t átalakítsa-e ¥-re.



Elvándorolt szövegrészek, például a USERINITALS opció leírásánál a USERNAME leírása szerepel.



Belső ellentmondások, például egy helyen definiál színeket, de nem a más szabványokban elfogadott értékekre, másik helyen meg ugyan az SVG-ben definiált színeket használja, de mivel a nevek egy részét már definiálta, rosszul, ezért azokat kénytelen átírni.

Stéphane Rodriguez, egy bináris fájlformátumok visszafejtésével foglalkozó szakember, sok, kevésbé nyilvánvaló, de hatásaiban sokkal súlyosabb hibát is kiderített. vi

Egyszerű, de katasztrofális hiba a tizedes törtként felírt számok tárolása, melyeket időnként végtelen tizedes törtként kezel (12345,12345 helyett 12345,12349999). A szabványból nem derül ki, hogy miért és hogyan teszi ezt, ez csak a referenciaimplementációban látható.

Az eredményül kapott XML is nagyon nehezen kezelhető XML-ként, például mert a sok különböző fájl közötti kapcsolat nem definiált, és ha mégis, akkor olyan bonyolult, hogy egy mező tartalmának megváltoztatásához 3-4 fájlt kell módosítani.

A dátumok kezelése is egy régi Excel típuson alapul, ami csak i. sz. 100-9999-ig képes kezelni az időt, és korrekt feldolgozásához ilyen kifejezések szükségesek:

[$-40C][Red][>120]_-* #,##0.00\ _F_-;\-* #,##0.00\ _F_-;_-* "-"??\ _F_-;_-@_-

Csak ízelítőül, a nehezen érthető kifejezés első utasítása az, hogy francia szokások szerint írja a dátumot. Ehhez a 40C kódot használja, aminek semmilyen közismert rendszer szerint nincs köze Franciaországhoz, egy belső Microsoft kód. Nehéz elképzelni, milyen nehézségeket jelent egy ilyen beépített programozási nyelv implementálása, a sok különböző rejtélyes kód keresztreferenciáival együtt.

A bitmaszk a szűkös memória korszakából maradt relikvia. Amikor még minden byte számított, pazarlás volt egy igen/nem értékre egy egész byte-ot elhasználni. Sokkal takarékosabb, ha a byte 8 igen/nem értéket tárol, például a TCP fejléc tartalmaz egy byte-ot, aminek a negyedik bitje jelenti, hogy a csomag acknowgledment, a hatodik pedig azt, hogy a kapcsolatot le kell zárni. Bizonyos programozási nyelvek elegáns és erőteljes eszközöket tartalmaznak az ilyen bitmaszkok kezelésére, mint például a C.


Bitmaszkok

Az XML céljai között viszont kifejezetten nem szerepel a tömörség, ezért az XML elveti a bitmaszkok használatát, ennek köszönhetően az XML nem is tudja kezelni a bitmaszkokat.

Az OOXML mégis hemzseg a különböző bitmaszkoktól. Ezek nem bővíthetőek (ha 32 bit van, egy 33. opciót elhelyezni körülményes), nem kezelhetőek és feldolgozhatóak XML (XSLT) eszközökkel, nem olvashatóak, azaz nagyjából nem-XML formátummá változtatják az OOXML-t.

Ráadásul a helytakarékossági érv irreleváns, hiszen minden OOXML fájlt tömörítve tárolnak.

Zárt szoftverekre hivatkozás


Zárt szoftverekre hivatkozás

Mivel az OOXML egyik fő feladata a régi Microsoft formátumokkal való kompatibilitás, számtalan, ezekre a formátumokra utaló opció szerepel benne. A teljesség igénye nélkül néhány:



useWord97LineBreakRules



shapeLayoutLikeWW8



truncateFontHeightsLikeWP6

Az ezekhez megadott leírás szerint az alkalmazásnak úgy kell viselkednie, mint a megjelölt alkalmazásnak.

Ezek implementálásához a fejlesztőnek be kell szereznie egy példányt a réges-régen elavult és beszerezhetetlen termékből, és visszafejtenie, amit jó eséllyel tilt a licencszerződés. Vagy az, aki az OOXML-t meg akarja valósítani, ezeket nem implementálja, és így előáll az a helyzet, hogy ezt a szabványt nem lehet teljesen implementálni. Márpedig mi szükség egy megvalósíthatatlan szabványra?

A helyes eljárás az lett volna, ha useWord97LineBreakRules helyett van egy LineBreakRules változó, aminek van több jól definiált értéke, leírással, melyek közül egy a Word97, szintén teljes leírással. Természetesen így bárki írhatna OOXML elemzőt, de ez nem volt cél megalkotásakor.

Hasonló hivatkozások nagy számban fordulnak elő az OOXML-ben, forrásunkban 12 van kiemelve, de kitartó kereséssel tucatjával találhatók.


Méretek

Az OOXML 6456 oldalas. Ez rettenetesen sok, például kb. nyolcszorosa az ODF-nek, ami pedig ugyanezt a célt szolgálja, vagy hatszorosa a Bibliának, ami sokkal komolyabb célokat szolgál. Ennek egyik legfontosabb oka, hogy nem használ föl már létező szabványokat (kezdve a naptártól és mértékegységektől, egészen az SVG komplexitású rendszerekig), és a spanyolviasz újra felfedezése helyigényes.

A nagy méret dacára az OOXML eddigi útja gyors volt. Tulajdonképpen olyan gyors, hogy az nem is teljesen jó. Rob Weir vii hasonlította össze néhány más szabvány méretét és az első publikálástól a szabvány elfogadásáig tartó időt. Függetlenül a szabványtestülettől és a szabványtól, az átlag az egy oldal/nap sebesség. Ez igaz az Ecma-hoz a Microsoft által benyújtott két másik szabványra is, a C# (1.2 oldal/nap) és a C++ (0.7 oldal/nap) is ebben a tartományban mozgott. Ezt az átlagsebességet tartva az OOXML finomítása 2024-ig tartana.

Az OOXML 18.3 oldal/nap sebességgel száguldott végig az ellenőrzésen és hibakeresésen. Talán nem is meglepő, hogy ilyen sok sebből vérzik.


Jogi problémák

Korábban már kiderült, hogy sok opció megvalósítása igényli kereskedelmi forgalomban nem hozzáférhető, zárt forráskódú, szélsőségesen korlátozó licencfeltételek mellett forgalmazott alkalmazások belső működésének ismeretét. Ez már önmagában is súlyos, bátran leküzdhetetlennek nevezhető akadály.

Az OOXML név szerint is hivatkozik a Windows Media File és RTF formátumokra. Mindkettő zárt, a Microsoft tulajdonában lévő formátum, ezért szabványos és legális megvalósításuk lehetetlen.

Talán még súlyosabb problémát jelentenek a szabadalmak. A Microsoft évek óta százával szerez szabadalmakat megoldásaira. Ez a szabadalomportfólió rendszerint nehezen érthető, jogilag ingatag, és méreténél fogva áttekinthetetlen fenyegetés mindenkinek, aki az OOXML-t meg akarja valósítani.

A szabadalmak fenyegetésének elhárítására a Microsoft két dokumentumot viii is megfogalmazott, mindkettőben engedélyt ad minden olyan szabadalom felhasználásához, ami szükséges az OOXML implementálásához. Csakhogy az implementáláshoz semmilyen szabadalom nem szükséges (fordítóprogramok, formátumleírások, stb. szükségesek), ezért ugyan ezek a kifejezések emberileg érthetőek, jogi szempontból üres halmazt definiálnak. A kétféle értelmezés közelítéséhez hosszadalmas jogi eljárások és perek szükségesek, ami ismét nem könnyíti meg a megvalósítást.
Zárt fejlesztési eljárás

Az Ecma eredeti célja az volt, hogy:

produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats fejlesszen egy, az Office Open XML-el kompatibilis szabványt irodai alkalmazásokhoz, az Ecma International eljárásával.

Jól látható, hogy az OOXML születésének pillanatától fogva gyártófüggő. Ez vonatkozik az eredeti megalkotására, a módosításokra, és az esetleges későbbi fejlesztésekre is.

A nyílt szabványok fejlesztését, módosítását és karbantartását általában nyitott szervezetek végzik, nyílt eljárásokkal. Ilyen az IETF, ami sok hálózati protokollt gondoz, a W3C, ami a világháló formátumainak nagy részéért felel, vagy éppenséggel az OASIS, ahonnan az ODF is érkezett (sok más szabvány mellett). ix Az OOXML karbantartását a Microsoft végzi, teljesen ismeretlen és érthetetlen eljárások szerint. x

Erre jellemző példa, hogy nem sokkal az ISO-hoz való benyújtás után az Ecma weboldaláról lekerült az addig használt, egy fájlból álló (47 megabyte-os) verzió, és egy 5 külön fájlból álló, átszervezett „akármi” került a helyére. Ennek semmilyen logikus oka nincs, hacsak az nem, hogy az ellentmondások gyűjtésekor használt oldalszámok így el vannak csúszva. Szerencsére az eredeti

fájl is hozzáférhető, enélkül nem lehetne érdemben vizsgálni a szabványt, hiszen az ISO-hoz még az egy fájlból álló verzió került.


A szavazás érdekességei

A Microsoft és képviselői több alkalommal követtek el megkérdőjelezhető cselekedeteket más országokban. Ezek a teljesség igénye nélkül:

  • Spanyolországban a Microsoft képviselője szelektíven szerkesztette Andalúzia leveleit, így azt sugallta, hamisan, hogy Andalúzia támogatja az OOXML-t. Az andalúz kormány kénytelen volt írásban tiltakozni ez ellen xi .
  • Ausztráliában a Microsoft képviselője kijelentette, hogy az OOXML lesz a de facto szabvány, bárki bármit tesz. xii Az ISO szabványosítási eljárás egyik célja éppen az ilyen monopóliumok/vendor lock-in megakadályozása. Ugyanitt hangzott el, hogy az OOXML 2000 oldalról nőtt meg 6500-ra, a sok kívülről érkezett módosítási igény miatt.
  • Hollandiában több hónapi munka után tisztázták a technikai problémákat, és összeállították a „Nem, megjegyzésekkel” szavazathoz szükséges dokumentumot. Az utolsó ülésen majdnem egyhangú döntés született – csak a Microsoft képviselője szavazott nemmel. Így a Hollandiában érvényes szabályok szerint a szavazat „tartózkodás” lett, amivel Hollandia kizárta magát a szabvány további alakításából. xiii Többen nem érzik helyesnek, hogy a szabványt kidolgozó szervezet ilyen módon elfojthatja az ellenvéleményeket.
  • Portugáliában ellenérdekelt szervezetek képviselőit nem engedték be az ülésterembe (!), másokba pedig a szót fojtották bele xiv .

A szavazatról
Több alkalommal merült föl, hogy az esetleges hibákat majd a következő fázisban (BRM) kijavítják, nyugodtan lehet „Igen, megjegyzésekkel” szavazatot adni a problémáktól függetlenül. Pedig nem lehet. Az ISO/IEC JTC1 szabályzata szerint háromféleképpen lehet szavazni: xv

  • Elfogadás: ez esetben technikai megjegyzéseket nem lehet fűzni a szabványhoz.
  • Elutasítás, a technikai okok felsorolásával. Fel kell sorolni megoldási javaslatokat is minden problémára. A problémák javítását a szavazó országnak vissza kell igazolnia, és így a javítások után a szavazat megváltoztatható elfogadásra, ha a javítások jók voltak.
  • Tartózkodás.

Tehát „Igen, (technikai) megjegyzésekkel” szavazat nincs. Azaz, ha vannak technikai problémák (és elég egyértelműen vannak), akkor nemmel kell szavazni.

Kérésünkre összeállította: Tomka Gergely (Az SzSzI volt munkatársa, LME tag (volt elnökségi tag), meggyőződéses szabad szoftver párti, gyakorló rendszergazda)

i: 
http://ec.europa.eu/idabc/en/document/2592/5588
ii: 
http://www.oasis-open.org/
iii: 
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43485
iv: 
"Ecma is the inventor and main practitioner of the concept of 'fast tracking' of specifications drafted in international standards format through the process in Global Standards Bodies like the ISO. Since 1986, when fast tracking was introduced to ISO, over 75% of fast-tracked standards have been fast-tracked through Ecma."

v: 
http://jtc1sc32.org/doc/recent/JTC001-N-8530.zip
vi: 
http://www.arstdesign.com/articles/OOXML-is-defective-by-design.html
vii: 
http://www.robweir.com/blog/2006/12/notable-achievement.html
viii: 
http://www.microsoft.com/interop/osp/default.mspx http://www.microsoft.com/office/xml/covenant.mspx
ix: 
Érdemes tudni, hogy mindhárom szervezet munkájában részt vesz vagy részt vett a Microsoft

x: 
http://web.mit.edu/~stevenj/www/ecma376.html
xi: 
http://www.groklaw.net/article.php?story=20070723235113424
xii: 
http://www.groklaw.net/article.php?story=20070809103920651
xiii: 
http://isoc.nl/michiel/nodecisiononOOXML.htm
xiv: 
http://wiki.ansol.org/CT-173-LDD-Meeting-002
xv: 
http://www.noooxml.org/votingrules

1. oldal


Magunkról
  Tevékenység, célok
  Elérhetőség
Projektek
Szoftverek
Oktatás
Jogi tanácsadás
Közlemények
  Sajtóanyagaink
  Állásfoglalásaink
  Kötelező közzétételek
  Rólunk írták
Hasznos linkek
WIKI