Vlákno názorů k článku Microsoft získal ISO standard na Open XML od Tom - Uvedeny priklad mluvi za vse... co ma OOXML...
-
Tom (neregistrovaný)Uvedeny priklad mluvi za vse... co ma OOXML spolecneho s ISO standardem mi zustava utajeno.
http://jankuv.blog.lupa.cz/0803/ooxml-versus-odf-lepsi-jeden-priklad-nez-tisice-stran-dokumentace -
Necitite se vsichni trapne? Prijdete tu s nejakou blbosti, ktera je mozna neprijemna ci nesmyslna, ale funkci toho formatu nijak nedegraduje a uz jste odbornik?
Tak co kdybychom nize zalozili vlakno, kde bychom napsali jak stupidni je, ze ODF umoznuje vkladat binarni data primo do XML dokumentu (OOXML pokud vim, tak ne, dava je vedle), jak stupidni napad je ukladat uzivatelsky definovane styly do stejneho souboru s daty, jak stupidni je, ze v ODF stale zustavaji TOTALNE NEZDOKUMENTOVANE volby typu OutlineLevelYieldsNumbering ci TableRowKeep, ktere maji vliv na zobrazeni dokumentu a jejich ekvivalenty ECMA uz pred nekolika mesici vyradila z dokumentace OOXML do annexu a navic jsou na rozdil od ODF plne zdokumentovane.......
Jestli nejste schopen najit na OOXML nejakou opravdovou chybu se zasadnim praktickym dopadem, tak se radsi nevyjadrujte. Akorat se ztrapnujete. To, co tu pisete, vas mozna nastve, ale za vecer byste si na to jako developer zvykl a hotovo.
Mnoho povyku pro nic. Hlavne ze si kopnem do MS a poplacame se po zadech. Na bliti. -
Rejpal (neregistrovaný)
Co takhle ty stovky míst, kde jsou chyby či nedostatky způsobující nejednoznačnou interpretaci? (Chyby ve větách, nejsitota, zda jsou jednotkou úhlu stupně či radiány a podobně.) I kdyby se velikost písma nastavovala třeba na šesti místech šesti různými způsoby, pořád ještě by to tolik nevadilo, kdyby to bylo všude *perfektně* popsáno. Což ovšem není. A není možné z toho v tak krátkém čase tyhle chyby vymýtit. Nebo přinejmenším v BRM verzi se to nepovedlo.
Matně se mi vybavuje, jak vypadá třeba takový standard Common Lispu. Má zhruba 1200 stran, a i po deseti letech standardizace nakonec bylo kromě samotného standardu vydáno kolem 370 tzv. "cleanup issues" (zde, v duchu HyperSpecu jsou perfektně křížově referencované se všemi částmi standardu, kterých se týkají), které formálně nejsou součástí standardu, ale vysvětlují některé části, včetně motivace zúčastněných ohledně toho, jak nakonec rozhodli ve sporných záležitostech, říkají, jaký dopad na jazyk mají příslušná rozhodnutí, co by znamenalo jejich nepřijetí, co znamená jejich přijetí a podobně.
Kdyby takhle perfektní dokumentace byla k OOXML, tak ani nehlesnu, protože Common Lisp je v mnoha směrech stejně špatný, jako OOXML - velmi kompromisní, pragmatické, v mnoha směrech "hnusně špinavé" řešení, ale aspoň je u něj na čem stavět. Jenže já nevěřím tomu, že kvalita OOXML někdy dosáhne takové úrovně, jakou má rozsahem sotva pětinový standard Common Lispu. Bohužel se nepohybujeme v oblasti matematiky a tyhle zdánlivé "osíračky" není možné ignorovat, má-li takto rozsáhlý dokument být vůbec použitelný. Růžové brýle od Microsoftu na očích hlasujících implementátorům moc nepomůžou.
-
To jsou furt stovky, tisice... furt jen reci. Tak si projdete ty stovky chyb, ktere byly na BRM schvaleny jen hlasovanim a ukazte mi ktere z nich jsou natolik zavazne, ze by OOXML nemohl byt standardizovan -- nemyslite si doufam, ze je mozne schvalit bezchybny standar nebo ze neco takoveho dokonce existuje? :-) Do te doby uz me fakt nebavi poslouchat, jak tu vsichni jak roboti omilaji, ze OOXML ma stovky chyb.
Vyse jsem jasne popsal problemy ODF, a to nejsou vsechny. Proc jste tak nekricel kdyz se schvalovalo to? To vam nevadilo? Nebo jste se proste jen neobtezoval to zjistovat, protoze ODF neni od Microsoftu, tak co by...
Nadavat na zdokumentovanost OOXML je smesne a hodne odvazne. Pri tom, co ODF vubec nepopisuje a nespecifikuje.... OOXML ma mnohem lepsi dokumentaci. Podrobnejsi standard, lepsi e-booky, lepsi weby s developerskou tematikou. Kdyz uz ma kvuli legacy vecem nejake blbosti, alespon je zdokumentuje. Na rozdil od ODF. -
Vase reakce malinko zavani agresivitou. Zkuste zvolnit a zamyslet se timto smerem. Me osobne vadi 2 veci:
1) Opravdu si myslite, ze MS format musi byt takovym otesankem na 6000 stran dokumentace (uz jen z principu to je "prilezitost" pro vznik vice chyb at uz tech nechtenych nebo tech "nedomyslenych"). Skoro by se dalo rict, ze zneprehlednovat a zbytecne zeslozitovat v podani MS = hazeni klacku pod nohy.
2) Nelibi se mi zpusob, jakym MS svuj format prosadil - pripada vam to ok? I kdyby to bylo z 1/3 pravda, tak je to neakceptovatelne (nechci zbytence nafukovat bublinu, ale prijde mi to vazne nefer).
PS I.: Chyby naleznete skoro ve vsem a vetsinou se daji i opravit - problem je v tom, jaky k tomu zaujmete postoj...
PS II.: Myslim, ze komunina kolem ODF neni takova banda ignorantu jako vedeni MS. Jestlize bych si mel vsadit svuj rocni plat na to, kdo bude lepe reflektovat na pozadavky odborne komunity, vsadim jednoznacne na ODF. -
1) Vite kolik ma ODF s adekvatnim formatovanim + vsechny standardy, ktere je potreba reimplementovat, protoze je Sun zprznil? (za vse jmenujme SVG a XSL-FO)... pres 3000 stranek... Na FUD o 600 strankach zapomente. To ma s radkovanim 1, kdezdo OOXML pouziva 1,5.
MS delal format tak, aby jeho implementace byla nejjednodussi pro nej. To je proste konkurencni boj. Kolik si myslite, ze toho Sun zmenil v ODF nez ho dal ke standardizaci?... moc toho urcite nebylo. Prece by si dobrovolne neprodlouzil dobu nutnou k plne podpore toho standardu ve svem SW. Chrante se ruzovych predstav o Sunu, jak mu jde v prvni rade o dobro svych zakazniku a obycejnych lidi a pak az o sebe.
Navic specifikace OOXML obsahuje primo v sobe u kazdeho elementu fragment XML Schematu, ktery ho reprezentuje. Kdyby se to odstranilo (jako ze neni nutne, aby to tam bylo, i kdyz je to prakticke), bylo by to dalsich nekolik set stranek dolu.
2) Az uvidim dukazy, reknu na rovinu. Ted muzu rict jen to, ze pokud jsou spekulace zalozene na pravde, nebyl ten proces rozhodne OK. Jenze problem FLOSS komunity je ten, ze si nekde na blogu precte neco ve smyslu "jiste zdroje rikaji, ze mozna se mohlo stat, ze MS [doplne si vas oblibeny hrich]" a pak ve forech rozkrikuji "dyt je to jasne, se podivej, tady je to napsano, MS je svine, podplaci!". Chci regulerni vysetrovani, pak se o tom budu bavit.
Fakt je, ze IBM melo ty nejlepsi duvodu k FUDu, lzim a podpore takovych to "zkazku". -
Abraxis (neregistrovaný)1, Standardy ala SVG a XSL-FO neni nutne implementovat - proste pouzijes stavajici, kvalitni a odzkousene, knihovny. Zatimco u OOXML MUSIS vsechno napsat z 0 - nemas proste zadnou jinou moznost.
2, Dukazy se vali vsude na internetu. Nejkriklavejsi jmenujme treba oficialni dopis predsedy Norskeho institutu, kdy zahadnym zpusobem bylo doporuceni standardu schvaleno, ackoliv 80% clenu nesouhlasilo (detaily viz google) -
Suchý čert (neregistrovaný)Tou možností použití existujících knihoven bych si nebyl tak jistý.
http://www.root.cz/zpravicky/oss-alliance-vystupuje-proti-schvaleni-openxml/193112/ -
2) A co kdyz reknu, ze IBM ci Sun ze zoufalosti a strachu z toho, ze OOXML projde, podplatili Norske uredniky, aby se takhle ozvali?
Zajem Sunu a IBM na shozeni OOXML je naprosto evidentni a doslova extremni a zvlast IBM neni v uplatcich a ignorovani etickych pravidel zadny novacek. Tvrzeni proti tvrzeni. Dokaz to tvoje necimjinym nez clanky v blozich a novinach. Chci videt naprosto regulerni soudni vysetrovani podezreni z uplatku. Do te doby si svoje "dukazy" nech pro sebe. -
TableRowKeep pokud vím neovlivňuje rozložení, ale chování editoru při úpravách tabulek, a OutlineLevelYieldsNumbering vypadá jako nějaký nápad, který někdo zapomněl doimplementovat, protože jsem k tomu ve zdrojových kódech nenašel žádný aktivní kód, jen jednu nepoužívanou globální proměnnou. Proč by to tedy mělo být ve specifikaci formátování dokumentů?
