A GNOME Foundation állásfoglalása az OOXML mögött álló ECMA TC45 bizottságban való részvételéről

GNOME

A GNOME Foundation-t az elmúlt időszakban több olyan vád érte, hogy támogatja az OOXML elfogadtatását, mert részt vesz a Microsoft Open Office XML formátuma mögött álló ECMA TC45 jelű technikai bizottságban. Az alapítvány most egy állásfoglalást adott ki, amelyben reagál ezekre a vádakra. Leírja, hogy mi a szerepe a TC45-ben és mi az álláspontja az ODF-fel, az OOXML-lel kapcsolatban.

De hogyan került a GNOME Foundation az ECMA TC45-be?

A kiadott nyilatkozatból kiderül, hogy Jody Goldberg - aki a GNOME-alapú Gnumeric táblázatkezelő alkalmazás vezető karbantartója hosszú évek óta - korábban a Novell alkalmazottja volt, s mint ilyen, részt vett az ECMA névre hallgató, svájci szabványügyi szövetség TC45 jelű technikai bizottságának munkájában. A TC45 az a biztosság, amely az Open Office XML ECMA szabvánnyal (Standard ECMA-376) foglalkozik és amely jelenleg azon dolgozik, hogy az OOXML mihamarabb ISO szabvánnyá is váljon.
Jody tagsága a TC45-ben lehetővé tette, hogy további OOXML dokumentációkhoz, információkhoz jusson az általa végzett munka során. Később elhagyta a Novell-t, de felkérte a GNOME Foundation-t, hogy vegyen részt a TC45-ben, folytatva az általa végzett munkát. A GNOME Foundation mint non-profit szervezet csatlakozott az ECMA-hoz, hogy folytassa a munkát. Az állásfoglalás szerint azért, hogy biztosítsák, hogy az OOXML kellőképpen legyen dokumentálva ahhoz, hogy a szabad- és nyílt forráskódú szoftverek a lehető legproblémamentesebben implementálhassák azt.

Jody a TC-45 tagsága alatt több száz problémát vetett fel az OOXML dokumentáltságával kapcsolatban. Munkájának kézzelfogható, jelentős eredménye mutatkozik majd az OOXML FLOSS implementálása során.

Mi van most?

A GNOME közösség 2000-ben háttérbe helyezte a saját irodai programcsomag termékeit, hogy inkább a feltörekvőben levő OpenOffice.org projektet segítse. Emiatt a GNOME 6 hónapos kiadási ciklusában nem jelent meg office termék, annak ellenére, hogy a GNOME továbbra is támogatja az olyan projekteket, mint az Abiword, Glom vagy a Gnumeric.

Álláspont:

  • A GNOME elsődleges küldetése, hogy a szoftverszabadságot terjessze világszerte a felhasználók számára. A GNOME Foundation támogatja a GNOME projekt globális fejlesztői és közreműködői táborát e cél elérésében.
  • A GNOME Foundation tagja az ODF Alliance-nek, szenvedélyes támogatója a nyílt szabványoknak. A GNOME Foundation hiszi, hogy az ODF a legjobb választás az ipar és a kormányok számára arra, hogy együttműködjenek egy olyan nyílt dokumentum szabvány létrehozásban, amely példanélküli innovációhoz, nyilvános átláthatósághoz vezet.
  • Az, hogy a GNOME Foundation támogatta Jody Goldberg munkáját az ECMA TC54-ben, nem jelenti azt, hogy a GNOME Foundation jóváhagyta és támogatja a Microsoft OOXML ISO szabványként való elfogadtatását.
  • Noha a Microsoft dícséretet érdemelne, hogy információkat adott ki az OOXML formátumáról, a szabványosítási folyamat körül tanúsított viselkedése azt jelzi, hogy a szabványosítással nem az a célja, hogy innovációs platformot hozzon létre az ipar egésze számára, hanem folytatja reformálatlan, bűnös monopolista viselkedését.
  • A GNOME Foundation mélyen aggódik, hogy a szabványosítási folyamat befolyásolása kikezdi a nyilvánosság nemzetközi szabványokba vetett hitét, annak értékét illetve függetlenségét illetően. Mind az ODF, mind az OOXML komoly mértékben befolyásolt az implemetáltságából származóan, valószínűleg egyik sem hozza el az "egy igaz office formátumot" és mindkét formátum mögött álló közösség szerepet játszik a saját módján a bizalomba vetett hitt csökkenésében.

A GNOME Foundation figyelmeztet, hogy a szabad- és nyílt forrású közösségnek óvatosnak kell lennie a "fekete vagy fehér" (gyk: csak az egyik vagy csak a másik) megközelítéssel egy olyan folyamat felé, amely a szabványokat gyorsan a felhasználóik, szoftvereik és közösségük elleni fegyverré fordíthatja. Nagyon valós a veszélye annak, hogy a szabványok a szabadalmak sorsára jutnak: azért jöttek létre, hogy az innovációt és a megosztást ösztönözzék, de manipulálták az irányítás és a vissztartás érdekében.

Az állásfoglalás itt.

( biboka v | 2007. 11. 25., v – 11:55 )

Hmm.. ez érdekes. Lehet hogy naív vagyok, de nekem megint az jutott az eszembe, hogy ha a GNOME-os srácok ügyesek, akkor implementélhatják a formátumot GPLv[2|3] alatt, és abból jól jönne ki a közösség. (szerk: vagy addig szólnak be, amíg nem lesz implementélható)

Meg azért az sem utolsó szempont, hogy [az msn szempontjából] az ellenfél táborából felügyeli valaki ezt az egészet, és ha kell még oda tud lépni.

Azt viszont továbbra sem értem, hogy miért lenne jó egy célra két szabvány. Jó hogy az MS nyomatja, de leeshetne neki, hogy elkésett.

Szerintem ezzel lehet valamit kezdeni, az első tábla a bevétel eloszláshoz, a második meg az üzemi nyereség/veszteség. MBD - office nyeresége kicsit kevesebb, mint a Client - vista. kb 8% az éves különbség, de amúgy ingadozik.

http://www.microsoft.com/msft/download/Financial%20Operating%20Segment%…

( kkemenczy | 2007. 11. 25., v – 11:59 )

Mintha Jody Novelltől való távozásakor magával vitte volna a Novell internal állásfoglalását is... alig van eltérés a kettő között :)

( palmaci | 2007. 11. 25., v – 15:55 )

Szerintem a GNOME-nal vegre valakik realis latjak a dolgokat. Az, hogy most elbukott attol meg max 2 even belul szabvany lesz. Utanna majd beindul a MS gepezet. Igy a gnomenak lesz ralatasa esetleg 100%compatibilis plugint is tudnak csinalni a ooo.hoz. Mert az nagyon demagok gondolkodas, hogy elbukta az MS, nem. csak vesztet csatat de ahaborut ok nyeri mert szabvany lesz OOXML ezt lehet boritekolni, igen szoljon hozza a FOSS kozosseg, hogy minnel nyiltabb legyen es ha tenyleg nyilt lesz abbol meg nem lett baj hogy 2 szabvany van. legyen 100 szabvany csak legyen mod az atjarhatosagra. Es akkor mar teljes joggal lehet a OOo a MSoffice ellen polusa....

Ha lehet kapni x->y adaptert tetszőleges típusú villanykörtéhez, akkor csak dühítő és drága, de ezt megszokjuk. A baj akkor van, ha nem lehet kapni adaptert, vagy lehet, de csak gyengén világít vele a lámpa.

Ha technikailag mindegyik formátum rendben lenne, és nyílt lenne, akkor azt mondanám: "Én már csak egy kávét kérek".

Egyetértek, akármennyire nyíltak, ha ugyanarra két szabvány van, egy program fejlesztőjének két formátum kezelését kell implementálnia, ami fejlesztési időt vesz el a tényleges funkcióktól. Az MS-nek már az tiszta haszon, ha a konkurrencia jelentős idejét az ő formátumainak implementálása köti le.

legyen 100 szabvany csak legyen mod az atjarhatosagra.

A fo erv a szabvanyositas mellett, hogy egyseges legyen a szabvanyositott dolog es megkonnyitse a felhasznalok eletet. Ha 100 fele szabvany van, akkor pont ez nem fog teljesulni.

De tegyuk fel, hogy nem 100, csak 2-3 szabvany van. A szabvanyok kozotti konvertalas standard modjat ki fogja kitalalni? Egyreszt ez nem feltetlenul erdeke a szabvany benyujtojanak, masreszt a ket szabvany kozott nem feltetlenul lehetseges az automatizalt konverzio. Ha alapveto koncepcionalis kulonbsegek vannak egy dokumentumformatumnal, akkor csak a felhasznalo segitsegevel lehet jol konvertalni, a felhasznalot viszont nem erdekli az egesz formatum dolog, o ugyanazt akarja latni mindket esetben. Ilyen komplex rendszerek eseten se akarat (a benyujto reszerol) se technikai lehetoseg nincs a tokeletes konvertalasra. Ha pedig nem lesz tokeletes a konverzio, akkor minek az egesz szabvanyositas?

"legyen 100 szabvany csak legyen mod az atjarhatosagra."

nem tudom miert ezen kell lovagolni. A Linux mikor indult az volt a jelmondat a valasztas szabadsaga.... Hogy igen van 30 fele WM van 10 fele desktop. nem baj tok feleslegesen fejlesztenek azonos tudasu programokat (A Koffice-nak mi erteleme amugy mondja mar meg vki????) Igen nem baj hogy tobb szabvany van. Azt senki nem fogja meg akadajozni, hogy az MS szabvagy csinaljon belole. Mert azt fog. Van annyi penze hogy meg tegye(majd sunyiban megvessz mindekit kilora megeri neki). Es ezt a gnome-nal helyesen jol latjak. Szellel szemben.... Szerintem minden erdekelt (foleg az OOo) erdekelt lenne, hogy olyan szabavany legyen ami konnyen implementalhato nekik is ez lenne erdekuk....

Akkor mar legyen olyan a szabvagy hogy ne csak az MS-nek legyen jo. A doc meg xls formatum zart alig dokumentalt megis irja olvassa az OOo.

Tudomasul kell venni, MS office megy mindehol 90% feletti a piaci reszesedes. A szabavanyositas utan mar nem lesz erv arra hogy levaltsag a MS office akarhol is, mert nem nyilt szabvanyokat hasznal.

Es az is jo, hogy nyilt szabavany kivan csnalni az MS mert igy nem teheti meg hogy patent csinaljon es szedje a jo kis jogdijat. Amit a doc-val es az xls-val meg meg csinalhat.....

KOffice: KDE könyvtárakat használ, illeszkedik a KDE-be (nem csak a kinézetre gondolok, amit nagyjából az OOo is tud, hanem kio, kparts, gui elemek viselkedése). Gyengébb gépeken gyorsabb. Maga a koffice irodai alkalmazások írásához közös felületet ad, és olyan alkalmazások is részei, amik nincsenek OOo-ban (pl. Krita). A szokásos irodai komponensek (pl. a szövegszerkesztő) egyelőre gyengébbek és nem tökéletesen támogatják az ODF-et, viszont helyenként más a koncepciójuk (pl. frame-ek a szövegszerkesztőben).

Ha valaki csinál konvertert, az kétirányú, ami ugyanazt csinálja mindkét irányba. Tehát ebből nem lehet gond. A szabvány megmondja, hogy egy egy dolog pl. hogyan jelenjen meg. Ezt meg csak össze kell párosítani a másikkal, annak a tulajdonságait használva.

> Ha pedig nem lesz tokeletes a konverzio, akkor minek az egesz szabvanyositas?
Ha pontos a szabvány - és nem olyan, hogy ennek megvalósítása: lásd off 97, az meg nincs sehol leírva - akkor miért ne lehetne jó a konverzió?

Hogyan kell matrixok es komplex szamok kozott konvert kesziteni? Ha koncepcionalis szinten ket kulonbozo dologrol van szo, akkor ez elvileg lehetetlen..

Konkret peldat nem tudok mondani, mert nem vagyok benne fejlesztoi szinten semelyik szabvanyban, de csak a pelda kedveert tegyuk fel, hogy szoveges dokumentum eseten:

- "A" szabvany megengedi azt, hogy egy szamozatlan listan belul legyen egy beagyazott szamozott lista
- "B" szabvany szamozatlan listan belul csak tovabbi szamozatlan listakat enged kesziteni

Most akkor mi tortenjen ha A-rol akarnak B-re konvertalni?

- Mondja, hogy nem lehet konvertalni
- Konvertalja szo nelkul a szamozott listat szamozatlanra?
- Dobjon fel egy popupot, hogy mi tevo legyen?

Egy ilyen komplex dolognal, mint a dokumentumformatumok, nem letezhet tobbfele szabvany. Ket eset lehetseges:
- A ket szabvany, ugyan mashogy van megfogalmazva, de funkcionalisan ugyanazt tudja. Akkor minek ket szabvany?
- A ket szabvany funkcionalisan nem ugyanazt tudja, akkor viszont nem lehetseges konvertert irni, legjobb esetben is csak a funkciok kozos halmazara sikerulHET.

Erre szokta kiírni a mentés máskéntnél, hogy az eredeti formátum olyan dolgokat tartalmaz, amelyek nem menthetők az új formátumba.

Es ezzel mar termeszetesen meg is van oldva a 100 szabvany problema. Pl. akkor ezek szerint egy ODF <-> 7-bit ASCII plain text <-> OOXML konverzio teljesen jol biztositja az atjarhatosagot, legfeljebb n'emi informacio elveszik konvertalas kozben....

Mar a 100-fele karakter-kodolas kozott sem lehet rendesen konvertalni, gondolom a 100-fele (de legyen csak 3-4) dokumentum-formatum kozott lehet majd.

Olvasd el a második felét is annak, amit írtam. Ha nem tetszik az adatvesztés, akkor visszamented a doksit ugyanabba a formátumba. Ha konvertálni akarsz, akkor figyelembe kell venned a két formátum metszetét. Ha csak használni akarod, akkor meg használd.

Sehol nem mondtam, hogy a több szabvány jobb, de azt fenntartom, hogy egy dokumentált formátum jobb, mint egy dokumentálatlan.