Ha nyitottságot keresel a Microsoft OOXML-ben, ellentmondásokra találsz

Hír

A Szabad Szoftver Intézet a Groklaw alapján a következőket írta az OOXML (Microsoft formátum) ISO szabványosítása körül felmerülő problémákról.

A közintézmények azért követelik meg a nyílt formátumok használatát, mert el szeretnék kerülni az egyetlen szállítótól való függést (vendor lock-in), és azt a jövőbeli helyzetet, hogy az esetleg évtizedekkel korábban elmentett dokumentumaikat nem tudják megnyitni, mert azokon a gépeken már nem fut a megnyitáshoz szükséges régi szoftver, és új szoftvert a gyártó már nem kínál. A nyílt fájlformátum azért jelenthet megoldást ezekre a problémákra, mert a formátum leírása alapján bármikor új szoftver fejleszthető, ami képes azt megnyitni.

A korábbi verziók által elementett fájlok megnyitása régebben is problémákat okozott a Microsoft Wordben, és a legújabb verziónak is problémát okoz Word 2.0-ból mentett fájlok megnyitása, tehát egy 15 éve keletkezett fájl ma már nem nyitható meg tökéletesen – ez állapot elfogadhatatlan a bíróságokon és egyéb közintézményekben. Erre a problémára akkor jelenthet megoldást egy nyílt formátum, ha külső forrásokra támaszkodás nélkül a lehető legpontosabban leírja, hogyan kell az adott fájlformátumot értelmezni.

Érthető, ha egy saját piaccal rendelkező gyártó fél a nyílt formátumok bevezetésétől, mivel egy nyílt formátum könnyebbé teszi a versenytársak belépését az adott piacra. Esetünkben az adott területen kötelezővé vált a nyílt formátumok használata, így a monopolhelyzet fenntartása is nehezebb. A gyártó számára ebben az helyzetben az lenne az ideális, ha a nyílt formátumok formai követelményeinek megfelelve monopóliumát megtarthatná, és ennek egyik eszköze, hogy olyan „nyílt” formátumleírást publikál, melyet csak ő tud megvalósítani.

Az idézett groklawos cikk szerzőjének véleménye szerint a Microsoft viselkedése egy csapodár férjhez hasonló, aki mindig csak ígérget, ám csak látszólag teljesít, és folyamatosan különböző kifogásokat hoz fel mentségére. A Microsoft által beadott, az ECMA által elfogadott és az ISO általi elfogadást megcélzó OOXML szabvány például a fájlformátum egyes elemeinek leírása helyett csak annyit ír, hogy ezt ugyanúgy kell értelmezni, mint ahogy a Microsoft Word 95 csinálja.

A teljes írás itt.

( snq- | 2007. 01. 22., h – 16:06 )

:) elég erőltetett. az "aggodalomra intenek" fudon kívül van mélyebb üzenet?

"A Microsoft által beadott, az ECMA által elfogadott és az ISO általi elfogadást megcélzó OOXML szabvány például a fájlformátum egyes elemeinek leírása helyett csak annyit ír, hogy ezt ugyanúgy kell értelmezni, mint ahogy a Microsoft Word 95 csinálja."

Ez nem elég neked?

de, és az ecma-nak is elég volt:

Ecma International secretary general Jan van den Beld said: "The Open XML standard recognises the benefit of backward compatibility preservation of the billions of documents that have already been created while enabling new future applications of document technology."

( joco01 v | 2007. 01. 22., h – 16:13 )

A törekvés eddig jó, de mi lesz azokkal a dokumentumokkal, amiket jó régen nem nyílt formátumban mentettek el, azokat ki fogja nyílt formátumba migrálni? :)

( babo v | 2007. 01. 22., h – 16:28 )

A beküldés óta (még kora délelőtt volt) az SzSzI oldalán pontosabbá, korrektebbé és talán bővebbé vált az írás

( kupcsik v | 2007. 01. 22., h – 17:17 )

Az objektivitas vegett meg lehetett volna emliteni, hogy a Mikroszoft segiti egy open-source konverter fejleszteset is.
http://odf-converter.sourceforge.net/

Azzal persze egyetertek, hogy mivel mar van odf, ezert teljesen folosleges ooxml. Talan csak arra jo (MS-nak) hogy jobban illeszkedik a Wordhoz, ezert kevesbe kell atdolgozni azt. Talan.

Milyen objektivitást kérsz számon? A FOSS zealotok ugyanúgy élnek a FUD eszközével, valaki büszke is rá, mert minden eszközt megengedhetőnek tart a szent cél érdekében, valaki csak tudatlan birka, és szajkózza, amit máshol hallott.

Az OOXML-t lehetne alázni FUD-mentesen is, tisztán műszaki szempontokat figyelembe véve, mint ahogy ezt meg is teszik páran. Amit én leszűrtem:

A szabvány bonyolult, oldalszámra is sokkal több, mint pl. az OpenDocument, ráadásul nem használ fel semmilyen meglévő szabványt. Egyszerűen az MS dokumentumformátumok belső struktúráit képezték le XML-re, miáltal ha az MS-en kívül más is meg akarja valósítani maradéktalanul, kénytelen lesz az MS Office belső dolgait (akár hibáit!) hűen lemásolni. Az OpenDocumentnél nem a StarOffice bináris fájlformátumát vették alapul, hanem kidolgoztak egy újat, ami mentes minden implementációból adódó kompromisszumtól, építettek a meglévő szabványokra (Dublin Core, MathML, SVG stb.). A régi bináris formátum 100%-os támogatását nem bukták el ezzel, hiszen az azt értelmező kód megvolt és megmaradt.

Amit nem kellene hangoztatni:
Microsoft egy saját nyílt formátumot tervezett, az OOXML-t (melyet egyedül a 2006 novemberében megjelent Microsoft Office 2007 kezel.

Out of the box persze hogy csak az Office 2007, de van konverter Office 2000, XP és 2003-hoz, ingyen letölthető a Microsofttól. A régi OOo verziók közül az ODF-et kezeli az OOo 1.1.5 (és az azonos patchlevelen levő StarOffice 7) aztán annyi. Ha kijön az ODF 1.1, utána az 1.2, nem hiszem, hogy backportolják. Magyarul csak a legújabb verziókkal fog menni.

A korábbi verziók által elmentett fájlok megnyitása régebben is problémákat okozott a Microsoft Wordben.

Biztos így van, bár konkrét példák nem ártanának. Pl. én is szívtam DOS-os Word 5.0 fájlok konverziójával Word 95-be, főleg mert a DOS alatt a magyar ékezetes betűk megvalósítására jópár sufni program létezett, sajátos, nem szabványos kódlapokat használtak. A Windows-os Word-ök között már jobban ment a dolog - főleg a megfelelő konverterek telepítése után, melyek nem feltétlenül részei az alaptelepítésnek. A DOC formátum a Word 97-nél változott utoljára jelentősen. Ezzel szemben nemrég olvastam egy hibajelentést, hogy egy cég frissített OOo 2.0.x-ről 2.0.x+1-re, és a táblázatcellák margói megnőttek, miáltal a dokumentumaik szétestek. Sajnos nem jegyeztem meg a hibaszámot, csak bemondásra el kell hinni. OOo - KOffice adatcseréről ne is beszéljünk, ez még nem megy és kész. A nyíltság nem csodaszer.

>> A régi bináris formátum 100%-os támogatását nem bukták el ezzel, hiszen az azt értelmező kód megvolt és megmaradt.

szerintem érdekes kérdés, hogy mit nevezünk 100% kompatibilitásnak / támogatásnak: beolvassa az előző verzióval mentettet; vagy beolvassa, és úgy menti az új formátumban, hogy az használható marad (annak az összes legacy stuffjával együtt)? a felhasználók szempontjából nézve minek van értelme?

(ha kitekintünk a szobaforradalmárok világából, sokkolólag hathat az a mérhetetlen mennyiségű (akár ráfordított időben / pénzben kifejezve is) legacy office stuff, makró, vba "business logic", amit a kereskedelemben, iparban (etc, nem feltétlenül informatikai központú cégeknél) az évek során felhalmoztak, viccesen hangzik - de nem kevés esetben komolyan függenek is ezektől a mindennapi munkafolyamatjaikban)

(+ ennek tükrében mit nevezünk itt "régi bináris formátumnak"? az ooo/odf szempontjából régi bináris formátumot, vagy azt, ami a felhasználók túlnyomó többsége szempontjából régi formátum?)

"vagy azt, ami a felhasználók túlnyomó többsége szempontjából régi formátum?"

Sarkítasz már megint.
Túlnyomó többség azt se tudja mik azok a makrók.
Ennyit tudnak: "Word/Excel Makró az amiben vírus jöhet ezért nem szabad engedélyezni."

Szerintem rossz ötlet ilyen Word/Excel makrókra bízni az életünket.
Koncepcionálisan rossz.
------
gentóhuszár

én sem tartom jó ötletnek, hogy boldog-boldogtalan accessben mókol, én is őszintén lelkes híve vagyok a "minden implementációból adódó kompromisszumtól való mentességnek", és a "a meglévő szabványokra való építésnek", és szívesen alakítok kis közösségeket a hasonló gondolkodásúakkal, de ezzel nem oldottunk meg semmit

lehet hogy sarkítok, nem tudom. a felhasználókkal kapcsolatban pedig más tapasztalataim vannak.

Érdekes kérdések... A "régi bináris formátum" alatt a régi StarOffice formátumokat értettem, de nem vettem tekintetbe a makrókat, mert ha jól tudom a StarOffice 5 és 6 között (közben volt a Sun általi felvásárlás és a kód nyílttá tétele) nagy változások voltak az API-ban, ezért a makrók nem vihetők át. Azóta igen. De ez elméleti probléma, mert nem építettek tömegek a StarOffice 5 és elődei makrónyelvére.

(Az MS megcsinálta azt, hogy a WordBasic vagy az Excel 4 makrónyelve futtatható maradt a későbbi verziókban, ezek subsetjei lettek a VBA-nak.)

A lényeg persze hogy az MS Office VBA makróinak átvételi lehetősége lenne az OOo/SO-ba. Erre két próbálkozás van. A Sun fejleszt egy zárt kódú, pénzes eszközt (Macro Migration Wizard), ami a VBA kódot StarOffice Basic-re tudja alakítani. Egyszer majd kipróbálom, de kétségeim vannak: ha működne, már hallottunk volna róla. :) A másik megoldás a Novellé, nyílt forrású fejlesztés, elkezdték a VBA-t implementálni, csak az Excelre koncentrálnak, a saját OOo buildjeikbe bele is teszik.

Viszont aki sok VBA makrót, Access adatbázist stb. használ, az mi a fenéért akarna váltani OOo-ra most? Nem valószínű, hogy olcsóbban megússza az átállást, mint az esetleges frissítést (és frissíteni sem muszáj). Ráér akkor aggódni, ha a megszűnik a Microsoft, kihalnak alóla a régi programokat futtatni tudó gépek. Bár addigra már az OOo is be fogja olvasni ezeket, és megmenekül. :)

igazából nem is arra gondoltam, hogy szeretnének ooo-ra váltani, hanem feljebb írta valaki, hogy nincs is már szükség openxml-re, mert van teljesen szabványos odf (illetve továbbgondolva akár az ms is felhasználhatná, mint nextgen default office formátum)

Ja, hát azt nyugodtan megléphették volna, ha akarták volna. Az OpenXML melletti döntésre felhozhatók politikai indokok, gazdaságiak is (kevesebb munka), de a Microsoftnak is lehetősége lett volna az ODF formátum kidolgozásába beleszólni, és a felmerülő technikai nehézségeket megoldani.

Én csak a béta átalakítót próbáltam, de amit néztem az nem nagyon ment vele, csak az egyszerűbb makrók. Bizonyosan az újabb verziókban javul a hatékonyság. A Novelles VBA probálkozás számomra sokkal érdekesebb, mert megtartják az eredeti kódot... Kipróbáltam, nagyon sok dolog már megy és nagyon sok még nem. Amúgy lehet küldeni az egyik fejlesztőnek - Noel Powernek VBA-t tartalmazó munkafüzeteket. Nagyon segítőkész. Készítettem is Windows alá VBA-t tudó buildet :) Egész jó :)

most eltekintve attól, hogy o/p magánvéleménye szerint "A korábbi verziók (ez az, amelyik _előbb_ jött ki) által elmentett fájlok (téhát amit azzal (a korábbival) mentettek) megnyitása régebben is problémákat okozott a Microsoft Wordben (nyilván egy újabb (annál, amit az előbb korábbinak neveztünk) verzióval)", milyen tanulsággal szolgál az openxml vitában ez az évtizedes élményed?

ebben az időben a "szabad világ" számára vi + LaTeX jelentette a szövegszerkesztést.

Tudom, hogy nem így értetted, de ez kicsit úgy hangzik, mintha a vi+LaTeX ugyanarra való lenne, mint a WYSWYG szövegszerkesztők. Mindkettőnek van előnye és hátránya, és mindkettő másban jobb. SZVSZ másra is való. Én ma is elég gyakran használom a vi+LaTeX párost, nagy megelégedéssel.

( simca | 2007. 01. 24., sze – 23:09 )

"Well, one of the things that document metadata specify is the language of the document. The Open Document standard does this correctly. It uses (p. 61) the three-letter language codes of ISO-639, followed by a two-letter country code following ISO 3166. This allows for the specification of any of the world's languages. A three letter code allows for as many as 17,576 languages. ISO-639-3 in fact already encodes most of the world's approximately 6,700 languages. Open XML, on the other hand, does not follow ISO-639-3. Instead (section 2.18.52), it requires that languages be specified by means of two hexadecimal digits, e.g. 0x09 for English. That means that no more than 256 languages can be accomodated. The list of languages available is in the document referenced above on pp. 2531-2537 but for the two-letter hex codes you'll have to look elsewhere because Microsoft doesn't list them together with the languages. For some reason it gives a completely different set of non-hexadecimal codes ranging from 1025 to 58,380."

Gyönyörű.