České komentáře k OOXML byly vyřešeny

Jiří Kosek přijal od ECMA odpovědi na komentáře ČNI k Microsoft OOXML. Přibližně 90 % odpovědí je považováno za dostačující, a proto je prý čas říci „ano“.

14.1.2008 20:00 | Luboš Doležel (Doli) | IT novinky

Komentáře

[Ilfirin]

Tak a kde jsou ti, co minulý rok slavili porážku OpenXML? Ti co říkali, že se to pouze oddálilo byli považováni za pesimisty. A máme to tady. V tomhle kole to projde a bude to začátek konce ODF.

[pht]

Pokud ODF je tak spatny, ze jej nad vodou drzi jen to, ze je jedinym standardem, tak budiz po nem co nejdrive. Pokud OOXML projde a bude aspon trochu pouzitelne, bude to zacatek kompatibility, a zda se oba formaty budou pouzivat soubezne ci jeden z nich pojde ukaze teprve cas.

[Pev]

bullshit

[frdrx]

Ba, ba.

[Dalibor Smolík]

Bezva. Takže když budu ukládat své archivní dokumenty v ODF v domnění, že mám zajištěno otevírání dokumentů "napořád", tak se jednou mohu dočkat nepříjemného překvapení.

[freshmouse]

By mě zajímalo, kde někdo tvrdil něco o porážce o OpenXML. Ale že by to byl začátek konce ODF, to si nemyslím.

[Jirka]

ODF tu bylo nějaký čas před OpenXML a bude i po OpenXML. Nezmění se vůbec nic. Ignoranti mi budou pořád posílat screenshoty cmd shellu s výpisy jako jpeg uložený (místo doc) v oxml a já se budu stále zbytečně rozčilovat.Ti rozumnějši použijí alespoň PDF/ODF (když už ne čistý text). A firmy budou svoje "dokumentové bohatství" stále tvořit v MS Office. A to ať bude OpenXML ISO nebo ne.

[Christof]

jpeg? tak to buď rád, že to není BMP ;)

[otula]

BMP je aspoň kvalitnější, než JPEG. Úplně nejlepší je, když dostanu od někoho firemní logo právě jako jpeg vložený do doc. Když požádám o logo ve vektorech, nechápou, co po nich chci

[ronny]

a dostal jsi nekdy firemni logo ve Wordu, ktere ale bylo vytvorene ve Wordu? :D

[otula]

Tak to fakt ne Každopádně by ale bylo také lepší, než to vložené - pokud by to nešlo jinak, stačil by printscreen při vhodném zoomu stránky

[jozka]

Pche, lidi, co jeste nedostali mapku vytvorenou v excelu nemaj pravo na stiznosti. Dotycny borec tvrdi, ze s excelem se da vsechno. Kdybych mu ale k polevce dal vidlicku, tak se urcite bude tvarit divne...

[Michal Čihař]

Japonští soudruzi tu taky dělají všechno v Excelu. Od plánování projeku až po dokumentaci testů. Není nic co by Excel nezvládnul .

[Kyosuke]

Bylo by divné, kdyby jediný program z Office, co stojí za to, něco neuměl. A když jsme u toho, jak se vám podařilo těch tisíc stránek POSIXu a tutorialu k Eclipse do něj přepsat tak rychle?

[Michal Čihař]

To se naštěstí jenom tisklo .

[Michal Vyskočil]

Q: Umí Excell načítat csv soubory?

A: Umí.

Problém vyřešen

[bzz]

neumi je ukladat v utf-8

[Michal Vyskočil]

To tolik nevadí, protože je to pravděpodobně stejně anglicky a jde především o ten import

[Stanislav Brabec]

Ano, dostal. Pak nezbývá, než se pokusit to "jako vytisknout" na PostScriptové tiskárně (nově možná i PDF), pak na to poštvat nějaký program, který to převede do zpět do editovatelného tvaru, a doufat, že nevznikne nějaká zrada. Pokud vznikne, tak vytisknout, naskenovat, vytrasovat.

Ba co hůře, asi před sedmi lety jsem dostal jsem ve Wordu celou knihu, která se měla tisknout na dvoubarevném tiskovém stroji. Výše uvedeným postupem jsem vyrobil PostScript, k tomu jsem napsal PostScriptová makra provádějící požadovanou barevnou separaci. Když jsem tlustý svazek fólií předal do tiskárny, vrátily se mi zpět - PostScriptový ovladač některá písmenka na některých stranách trochu "rozskákal". Zakázku nebylo možné dokončit, čistá ztráta byla pěkných pár tisíc za vyhozené fólie a práci.

Od té doby nedám na kvalitu výstupu z Wordu dopustit.

[Michal Kubeček]

Já jsem radši s požadavkem vektorového formátu opatrný, protože pak mi to pošlou v nativním formátu Corelu a jsem nahraný…

[otula]

To mně nevadí. Kolegovi jsme totiž koupili Corel 13, aby si furt nestěžoval, takže stačí jen zaběhnout k němu do kanceláře

[Dalibor Smolík]

Vzhledem k tomu, že nejsme grafická firma, s klidným svědomím požádám o zaslání dokumentu ještě v nějakém jiném formátu a vždycky mi bylo vyhověno.

[newman]

Vis, Ilfirine, Kefaline, za ty tri minuty, jsi je jenom proste predbehl, ber to sportovne. Jinak, samozrejme, preji [:ououzml:] at shnije v pekle (pokud je to vubec mozne :) ).

[danfis]

Bohuzel odpovedi nejsou verejne, takze se nedozvime, co na nich bylo dostacujici. Jedine, co vime je, ze to panu Koskovi staci.

[Dejv]

Tak nevim. Pana Koska jsem povazoval za "ceskou autoritu" ve svete XML a tak nejak jsem ocekaval, ze k OOXML se bude na zaklade prostudovani navrhu stavet odmitave. Ale jak tak sleduji zpravicky, ve kterych se mluvi o jeho (vstricnem) postoji k OOXML, tak zacinam mit pocit, ze jsem se mylil. Akorat nevim, jestli v OOXML nebo v panu Koskovi...

Dejv

[newman]

Ono spolehat na "autority" je osidne. Viz pripad Guntera Grasse, ktery byl taky povazovan za tzv. moralni autoritu co se tyce svedomi nemecky mluvicich ohledne druhe svetove valky a co se pak ukazalo? (Grass to sam rekl.) Ze Gunter na konci valky agilne vstoupil do Waffen SS a branil Viden u protiletadlove obrany.

Moje autoritativni rada zni, bacha na autority, aniz bych, jak by rekl Bernard, ti nechtel radit, prestoze by bylo radno... :)

[freshmouse]

Ono spolehat na "autority" je osidne. Viz pripad Guntera Grasse, ktery byl taky povazovan za tzv. moralni autoritu co se tyce svedomi nemecky mluvicich ohledne druhe svetove valky a co se pak ukazalo? (Grass to sam rekl.) Ze Gunter na konci valky agilne vstoupil do Waffen SS a branil Viden u protiletadlove obrany.

Ano, rozhodně bych Günterovi Grassovi vyčítal, že jako patnáctiletý hoch vstoupil do armády.

[Aleš Kapica]

Ano, jako patnáctiletý bych také vstoupil do armády. Jako třiadvaceticetiletý jsem mohl zodpovědně prohlásit: nasrat!

[newman]

Nevstoupil do armady ale do Waffen SS, zjisti si, co maji Waffen SS na svedomi a jaky je mezi nima a tehdejsi armadou rozdil.

[freshmouse]

Do armády, pokud vím, taky vstoupil -- a ještě dřív než do Waffen SS (právě jako patnáctiletý). Do Waffen SS potom přestoupil. Nicméně pointa je jinde.

K námořnictvu šel roku 1942 (tohle už samozřejmě nemám z hlavy), bylo mu patnáct. Válka už pár let běžela, ale Hitler byl u moci samozřejmě ještě dřív. Když to zaokrouhlím, tak Günter Grass od první třídy měl na očích tehdejší německou propagandu v plné síle -- a že jí bylo požehnaně. Řekni: může si sedmiletý kluk udělat nějaký rozumný názor, když po většinu života slyší, jak jsou Židi nižší rasa atd.? Těžko. A že roku 1944 přestoupil k Waffen SS, to je jen důsledkem pobytu u námořnictva.

Chvályhodné to jistě není, ale že bych vyčítal malému klukovi službu u zločineckých organizací, to opravdu ne. (Koneckonců, velká většina Němců podporovala Hitlera, takže prakticky v každé rodině najdeš někoho, kdo byl u Jugend, ale i jinde...) Spíš je blbé, že to tajil, ale to je jiná věc.

[alblaho]

Přesně tak. Zrovna jsem v Týdnu četl výtah z Grassovy autobiografie.

On jako teenager Hitlerovi věřil a v té době s jeho zkušenostmi to ani jinak nešlo. Vyčítat mu, že byl v SS je ovšem velmi silná káva, na to bych si já jako pětadvacetiletý uvažující člověk co vyrostl v míru a blahobytu fakt netroufl.

[Dan Ohnesorg]

Tak tohle je prirovnani na par facek.

OOXML proste dospiva ve standard a tak z technickeho hlediska neni co mu dale vytknout. Samozrejme nebylo prepracovano vsechno, ani nikdo necekal, ze bude. To co neni prepracovano se bude resit na zaverecnem zasedani a neco jeste bude akceptovano, neco bude neakceptovano. I kdyby nebylo nic akceptovano, 3% rozpor je dobry vysledek.

Uz pouhy fakt, ze Microsoft pristoupil na otevreny format je vyhra.

[mibo]

No troufnu si ric, ze Microsoft to neudelal z libovule, ale protoze slovo otevreny zacalo otvirat brany do mist, kde byl predtim jen on, avsak uznavam, ze to neni prohra, ale vyhrou by byl jediny format s jakymkoli nazvem a na jehoz budoucnosti by se nepodilel v 99.9 procentech Microsoft.

[Daniel Kvasnička ml.]

Naprosty souhlas...i s tema fackama Zrovna pana Koska si docela vazim.

Proste by se lide meli zacit smirovat s realitou -- OOXML ma legitimni pravo na existenci a zdaleka to neni format k zahozeni.

[zoul]

Uz pouhy fakt, ze Microsoft pristoupil na otevreny format je vyhra.

Já si pořád moc neumím představit, jak se kontroluje specifikace o šesti tisíci stránkách. Předpokládám, že něco jako požadavek na dvě nezávislé, navzájem kompatibilní implementace v tomhle případě neexistuje. Nemůže se tedy docela dobře stát, že každá z implementací OOXML bude vzhledem ke kvalitě specifikace kompatibilní akorát sama se sebou a na otevřený formát v tom hlavním slova smyslu tím pádem můžeme zapomenout?

[zoul]

Zkusil jsem se zeptat přímo pana Koska, odpověď mě moc nenadchla. Připadne mi krajně pravděpodobné, že si implementace tohohle „otevřeného standardu“ nebudou navzájem příliš rozumět, a že si oproti aktuální kompatibilitě kancelářských formátů nepomůžeme.

[Daniel Kvasnička ml.]

Jenze to rekl naprosto presne. Zjistitete si, co v ODF 1.0 vsechno chybi, abyste rozumne otevrel dokument z OpenOffice.org (implementovat pri dnesnim rozsireni OOo mezi ODF editory pouze ciste ODF 1.0 se rovna sebevrazde -- nebude to nikdo pouzivat, protoze v tom neotevre nic z OOo a protoze pokud se budete striktne drzet ODF 1.0, nebude vase aplikace k nicemu, zvlaste v oblasti spreadsheetu) a budete Microsoftu jeste dekovat, ze jeho specifikace ma 6000 stranek. Ferove by bylo secist pocet stran ODF s poctem stran zdrojoveho kodu OOo, ktery musite prostudovat, abyste naimplementoval dobrou podporu pro jeho dokumenty. Vsemi nenavideny de Icaza to vystihl naprosto presne: "I guess the fairest thing that can be said about a spec that is 6,000 pages long is that printing it out kills too many trees."

Navic neni jen oficialni specifikace, jsou i dalsi zdroje, jako jsou komunity ci knihy. Ukaz mi, kde najdu neco takoveho (opravdu si myslite, ze by Microsoft neco takoveho platil, kdyby chtel ostatnim implementatorum co nejvice zavrit dvere?) pro ODF. A kniha OASIS OpenDocument Essentials? Na muj vkus je az prilis zamerena na OpenOffice.org, na rozdil od Open XML - The markup explained, ktera se zameruje mnohem vice na samotny format a doprovazi ji 300 kB archiv ukazkovych dokumentu, se kterymi se v knize pracuje. Nebo treba Word 2007 Content Control Toolkit, open source nastroj pro vazani custom XML dokumentu na OpenXML pri zachovani kompatibility -- kde najdu neco takoveho pro ODF?

[zoul]

To jsme si nerozuměli, já se nesnažím tlačit ODF. (Nemám čas, sílu ani chuť snažit se zorientovat v těch tisícovkách argumentů pro nebo proti.) Jen chci nějaký obecně kompatibilní kancelářský formát, a proto mě zajímalo, jak velká je pravděpodobnost, že dva nezávislé týmy dojdou při čtení specifikace OOXML ke skutečně kompatibilním implementacím.

No a jinak si doopravdy nemyslím, že by Microsoft chtěl kompatibilní kancelářský formát – možná je to paranoia, však uvidíme.

[Filip Jirsák]

Zjistitete si, co v ODF 1.0 vsechno chybi, abyste rozumne otevrel dokument z OpenOffice.org (implementovat pri dnesnim rozsireni OOo mezi ODF editory pouze ciste ODF 1.0 se rovna sebevrazde -- nebude to nikdo pouzivat, protoze v tom neotevre nic z OOo a protoze pokud se budete striktne drzet ODF 1.0, nebude vase aplikace k nicemu, zvlaste v oblasti spreadsheetu) a budete Microsoftu jeste dekovat, ze jeho specifikace ma 6000 stranek. Ferove by bylo secist pocet stran ODF s poctem stran zdrojoveho kodu OOo, ktery musite prostudovat, abyste naimplementoval dobrou podporu pro jeho dokumenty.

Proč neustále trváte na tom, že software pracující s ODF musí být plnohodnotný kancelářský balík, který ODF používá jako svůj nativní formát?

Moje představa je taková, že např. škola pořádá školení, vystaví na webu přihlášku, kterou já můžu vyplnit a vytisknout nebo poslat elektronicky zpět. Buď může tu přihlášku vystavit v binárním formátu Wordu, nebo v RTF, které taky není nijak pořádně stdandardizováno a moc toho neumí, a nebo ji vystaví v ODF – a je jedno, v čem to předtím v té škole dělali. Já si to naimportuju do svého textového procesoru, který jinak nativně pracuje s úplně jiným formátem, vyplním, uložím zpět jako ODF a pošlu zpět. Jiný příklad – prodejce vystaví na webu svůj ceník, má tam nějaké formátování, sloučené buňky, vzorce pro výpočet ceny s DPH a v jiné měně – nemůže tudíž použít CSV. Já si to naimportuju do svého tabulkového editoru, a můžu si dělat různé třídění, filtry atd. Nebo mi někdo pošle návrh smlouvy – sice jde vlastně jen o text, ale bylo by dobré zachovat už hotové nadpisy, seznamy atd. Na druhou stranu se dá očekávat, že v tom budu něco upravovat, takže PDF není vhodný formát – stačí mi bohatě nějaký editovatelný formát, který zachovává strukturu textu. Podle mne budou případy použití nějakého přenositelného formátu dokumentů minimálně z 90 % tohoto typu. A je něco, proč by formát ODF 1.0 pro tahle použití byl nevhodný? A vyplatilo by se čekat další měsíce nebo roky na pokrytí těch dalších 10 % užití, když by navíc existovala spousta softwaru, který by ty další možnosti vůbec nepotřeboval a nemusel umět?

[Daniel Kvasnička ml.]

Moje představa je taková, že např. škola pořádá školení, vystaví na webu přihlášku, kterou já můžu vyplnit a vytisknout nebo poslat elektronicky zpět. Buď může tu přihlášku vystavit v binárním formátu Wordu, nebo v RTF, které taky není nijak pořádně stdandardizováno a moc toho neumí, a nebo ji vystaví v ODF – a je jedno, v čem to předtím v té škole dělali. Já si to naimportuju do svého textového procesoru, který jinak nativně pracuje s úplně jiným formátem, vyplním, uložím zpět jako ODF a pošlu zpět.

Co bude ta skola pouzivat? V 99% OpenOffice.org, pokud to tedy bude vystavovat v ODF. A produkuje tenhle software ISO ODF 1.0? Ne. Takze co bude, kdyz tam pouziji neco z nestandardizovanych fukci? Budete je urgovat, at si sezenou software, ktery dodrzuje ODF 1.0? A jakypak takovy sfotware mi proadite, ktery bych mohl nasadit ve skole?.........

Jiný příklad – prodejce vystaví na webu svůj ceník, má tam nějaké formátování, sloučené buňky, vzorce pro výpočet ceny s DPH a v jiné měně – nemůže tudíž použít CSV. Já si to naimportuju do svého tabulkového editoru, a můžu si dělat různé třídění, filtry atd.

No tohle je krasny priklad V editoru implementujicim ISO ODF 1.0 budete mit definitivni utrum. A pokud ten prodejce bude mit take takovy editor, nic takoveho nikdy nevystavi, protoze to v nem nevytvori. Takze? Prodejce bude mit OOo a vam nezbyde nez ho pouzit taky a standardizovane ODF v tomhle pripade nepripada v uvahu.

[Filip Jirsák]

Co bude ta skola pouzivat? V 99% OpenOffice.org, pokud to tedy bude vystavovat v ODF. A produkuje tenhle software ISO ODF 1.0? Ne. Takze co bude, kdyz tam pouziji neco z nestandardizovanych fukci? Budete je urgovat, at si sezenou software, ktery dodrzuje ODF 1.0? A jakypak takovy sfotware mi proadite, ktery bych mohl nasadit ve skole?

Co by bylo, ten dokument se zobrazí bez nějakého efektu, bez vloženého videa, nebude v něm zachována informace o kontrole graamtiky, nebo jakákoli jiná věc, která je pro vlastní obsah dokumentu nepodstatná, a kterou spousta editorů ani nemusí umět zobrazit, nebo používá nějaký jiný podobný nástroj, který je schopen pracovat přímo s daty dokumentu, a nakešovaná data tedy nepotřebuje.

Mimochodem, čemu říkáte „produkuje ISO ODF 1.0“? Třeba pro HTML je to definováno tak, že existuje nějaký popis formátu + popis, jak se zachovat v případě, kdy je formát o něco rozšířen. Za dokument HTML je pak považován každý dokument, který má předepsanou strukturu HTML dokumentu, a jehož rozšíření nejsou v konfliktu s definicí HTML dokumentu. Všimněte si, že to neznamená, že by takový dokument mohl obsahovat pouze to, co je definováno ve standardu. Říká se tomu dopředná kompatibilita.

Pokud vám to nestačí jako příklad z jiného formátu a jako jediná logická možnost, zde to máte ještě jednou, tentokrát jako citát ze specifikace ODF:

Documents that conform to the OpenDocument specification MAY contain elements and attributes not specified within the OpenDocument schema. Such elements and attributes must not be part of a namespace that is defined within this specification and are called foreign elements and attributes.

Conforming applications either MUST read documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place, or MUST write documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place.

Conforming applications that read and write documents MAY preserve foreign elements and attributes.

In addition to this, conforming applications should preserve meta information and the content of styles. This means:

[Daniel Kvasnička ml.]

No jasne, ale kde to potom jsme? OOo uklada vzorce a funkce do spreadsheetu a ODF je nepodporuje (vide a efekty jsou mi ukradene). To je sice hezke, ze se to da zabalit do terminu "dopredna kompatibilita", ale reknete sam: jak je tedy ISO ODF 1.0 vhodne pro realne nasazeni samo o sobe? (tzn. treba uplne bez OOo)

Kdyz to srovnate s tim, co produkuje Office 2007, tak to je IMHO blize OOXML nez je OOo k ODF 1.0. Nevim o nicem tak fatalnim, jako je nulove zdokumentovani tak zasadni vlastnosti pro tabulkovy kalkulator.

[happy barney]

bla bla bla.

Dopredná kompatibilita je viac ako všetko teraz, aj keď zle. Chybou OOXML je, že definuje všetko. Nevyužíva práce iných (import iných iso/čakateľov na iso).
celé ooxml by mali rozdeliť, a vydať aj napr tú vašu zbožňovanú normu pre zápis funkcií tabuľkového kalkulátora.

[frdrx]

bla bla bla

+1

[Filip Jirsák]

ale reknete sam: jak je tedy ISO ODF 1.0 vhodne pro realne nasazeni samo o sobe? (tzn. treba uplne bez OOo)

Ano, je. Máme na výběr mezi CSV, které umí uchovat jen tabulková data, o kterých nevíte nic – ani typ, ani formátování. Pak je tady formát ODS, který podporuje alespoň tu prezentační část tabulky – tj. pokud tabulku uložím, můžu jí někde jinde úplně stejně zobrazit – a je to pořád tabulka s jednotlivými hodnotami (v PDF můžu tabulku zobrazit též, ale těžko jí budu třídit nebo přerovnávat). Pokud si k tomu nějaký program chce ukládat i nějaké výpočty, má možnost. Ano, u editoru tabulek dnes pokládáme za samozřejmost, že umí i vzorce a funkce. Jenže k tomu, aby se napsal dobrý standard pro vzorce a funkce, je potřeba určitý (ne zrovna krátký) čas. Přitom užitečný je i samotný formát pro zobrazení tabulek – ostatně, jak často dostáváte „z venku“ (tj. např. z jiné instituce, která pravděpodobně bude mít jiný software) tabulky, ve kterých potřebujete něco přepočítávat? Nebudou minimálně stejně časté různé manažerské přehledy, kde se s hodnotami nic nedělá, jenom se různě přesouvají sloupečky? Takže co je lepší – čekat třeba další rok na dokonalý formát se vzorečky, a nebo teď hned vydat formát bez vzorečků, který třeba v 50 % případů plně postačuje, a který bude tvořit onu zobrazovací část formátu se vzorečky? Navíc každá aplikace má možnost zjistit, že si do buňky nějaká jiná aplikace uložila vzoreček, kterému ta moje aplikace nerozumí, a příslušně mne informovat („dokument obsahuje neznámé vzorce, při změně dat nebudou hodnoty přepočítány“)

Kdyz to srovnate s tim, co produkuje Office 2007, tak to je IMHO blize OOXML nez je OOo k ODF 1.0. Nevim o nicem tak fatalnim, jako je nulove zdokumentovani tak zasadni vlastnosti pro tabulkovy kalkulator.

Třeba záměrně chybné výpočty s datem, to je pro tabulkový kalkulátor nezbytná funkce. Standard pro vzorce a funkce má podle mne vypadat tak, že podle něj napsaná aplikace bude dávat vždy správné výsledky, a výsledky z libovolné aplikace budou naprosto totožné. To znamená nadefinovat i způsob práce s čísly v plovoucí řádové čárce, zaokrouhlování, přesně nadefinovat obory hodnot jednotlivých funkcí atd. Mám velké pochybnosti o tom, že vzorce a funkce OOXML půjdou pouze dle standardu naimplementovat tak, aby výsledky byly za každých okolností stejné, jako v Office 2007 (a teď pomíjím fakt, že Excel 2007 sice vzorce teoreticky umí, ale prakticky mu nejde ani násobení). Protože OOXML jistě popisuje vzorce z pohledu „jak to dělá Excel“ – při takovém popisu se ale snadno zapomene popsat některé „detaily“, které zvolená implementace řeší automaticky.

Takže abych to shrnul – než úplný formát pro tabulkový kalkulátor za x let, to raději hned formát určený pro prezentaci tabulkových dat, a vzorce dodělat později. A než hned vzorce záměrně chybné, nebo nadefinované tak, že různé správné implementace budou dávat různé výsledky, to raději vzorce později, a správně.

[happy barney]

píšete mi z duše, ja takú trpezlivosť nemám

[Kyosuke]

To znamená nadefinovat i způsob práce s čísly v plovoucí řádové čárce, zaokrouhlování, přesně nadefinovat obory hodnot jednotlivých funkcí atd. Mám velké pochybnosti o tom, že vzorce a funkce OOXML půjdou pouze dle standardu naimplementovat tak, aby výsledky byly za každých okolností stejné, jako v Office 2007 (a teď pomíjím fakt, že Excel 2007 sice vzorce teoreticky umí, ale prakticky mu nejde ani násobení).

Hmmm, to jsou velké ambice. Stačí se podívat na problémy s opakovatelností FP výpočtů i podle IEEE-754. Režimy zaokrouhlování, vnitřní přesnost jednotek... Ač výsledek je samozřejmě nepřesný, opakovatelnost výpočtu je dost důležitá. Opravdu jsem zvědav, jestli OOXML tohle řeší. Ono chce přemýšlení i v případě, že si člověk může režimy FPU jednotky nastavit a píše si to všechno sám. Jsem zvědav, jak to bude u Excelu.

[Daniel Kvasnička ml.]

ale reknete sam: jak je tedy ISO ODF 1.0 vhodne pro realne nasazeni samo o sobe? (tzn. treba uplne bez OOo)

Ano, je. Máme na výběr mezi CSV, které umí uchovat jen tabulková data, o kterých nevíte nic – ani typ, ani formátování. Pak je tady formát ODS, který podporuje alespoň tu prezentační část tabulky

A pak je tu OOXML, ktere ac samozrejme neni dokonale, tu matematiku podporuje a nevim o zadnem dostatecne solidnim argumentu, na zaklade ktereho by se dalo s urcitosti tvrdit, ze OOXML se nebude vyvijet, opravovat svoje chyby a vylepsovat se.

Přitom užitečný je i samotný formát pro zobrazení tabulek – ostatně, jak často dostáváte „z venku“ (tj. např. z jiné instituce, která pravděpodobně bude mít jiný software) tabulky, ve kterých potřebujete něco přepočítávat? Nebudou minimálně stejně časté různé manažerské přehledy, kde se s hodnotami nic nedělá, jenom se různě přesouvají sloupečky?

No tak verejna sprava je prece jen jedna z mnoha oblasti (navic i v te nejprimitivnejsi tabulce bude nejaky ten SUM()). Nehlede na to, ze i tam si to dokazu predstavit treba u nejakych sablon pro ulehceni vypoctu dani apod. Ale pak je tu jeste cely ekosystem B2B komunikace, na urovnich od vyrobnich hal az po management a tam si dovoluji tvrdit, ze podpora vzorcu a funkci bude hrat naprosto zasadni roli. Tam ODF neni v soucasne dobe pouzitelny.

Třeba záměrně chybné výpočty s datem, to je pro tabulkový kalkulátor nezbytná funkce. Standard pro vzorce a funkce má podle mne vypadat tak, že podle něj napsaná aplikace bude dávat vždy správné výsledky, a výsledky z libovolné aplikace budou naprosto totožné.

No nezlobte se na me, ale ve vami zminenych manazerskych prehledech nebude vypoctu s datem o moc vice nez toho scitani hodnot.

Protože OOXML jistě popisuje vzorce z pohledu „jak to dělá Excel“ – při takovém popisu se ale snadno zapomene popsat některé „detaily“, které zvolená implementace řeší automaticky.

Ale notak, vy si vazne myslite, ze vzorce v budoucich verzich ODF budou teoreticky navrzeny bez prihlednuti k soucasnemu fungovani OOo a budou tedy skvele navrzene? Ja tvrdim, ze Sun to udela uplne stejne -- tedy budouci standard pro funkce a vzorce v ODF bude v podstate popisem "jak to dela OOo". Opak tvrdi vetsinou ti, co se na Sun divaji ruzovymi brylemi.

[Filip Jirsák]

A pak je tu OOXML, ktere ac samozrejme neni dokonale, tu matematiku podporuje a nevim o zadnem dostatecne solidnim argumentu, na zaklade ktereho by se dalo s urcitosti tvrdit, ze OOXML se nebude vyvijet, opravovat svoje chyby a vylepsovat se.

No nezlobte se na me, ale ve vami zminenych manazerskych prehledech nebude vypoctu s datem o moc vice nez toho scitani hodnot.

A není to nakonec jedno, jestli ten formát vzorce nepodporuje, nebo jsou ty vzorce špatně? V obou případech je nemůžete používat. Pravda, jeden rozdíl to je – k formátu ODF můžete vzorce bez problému doplnit a na samotném ODF se nic nezmění. Když budete chtít opravit vzorce v OOXML, musíte vydat nový formát, budou zmatky v tom, která aplikace ve které verzi formátu ukládá…

Ale notak, vy si vazne myslite, ze vzorce v budoucich verzich ODF budou teoreticky navrzeny bez prihlednuti k soucasnemu fungovani OOo a budou tedy skvele navrzene? Ja tvrdim, ze Sun to udela uplne stejne -- tedy budouci standard pro funkce a vzorce v ODF bude v podstate popisem "jak to dela OOo". Opak tvrdi vetsinou ti, co se na Sun divaji ruzovymi brylemi.

Kdyby šlo o to popsat, jak to dělá OOo, jsou vzorce ve formátu ODF už od začátku. Jenže formát ODF se od začátku vyvíjí jako formát pro přenositelné dokumenty, a zároveň má být rozšiřitelný na nativní formát kancelářského balíku. OOo funguje jako referenční implementace – aby se ověřilo, že ten teoretický popis formátu bude v praxi doopravdy fungovat. Samozřejmě že „jak to dělá OOo“ hraje svou roli při vývoji formátu ODF, ale je to pomůcka, ne primární cíl. Naproti tomu Microsoft potřebuje nějaký standard pro svoje dokumenty. Dnes je moderní XML, tak prostě interní reprezentaci dokumentu Wordu místo do binárního formátu nově serializují do XML, a jako standard vydají, co a jak Word serializuje. Vidíte ten rozdíl? Účelem ODF je být standardem, v druhém plánu ho OOo používá jako základ pro svůj nativní formát. OOXML je nativní formát MS Office převedený do XML, a protože to začíná být důležité, snaží se MS tomuto již hotovému standardu MS sehnat nějaké kulaté razítko.

[Daniel Kvasnička ml.]

A není to nakonec jedno, jestli ten formát vzorce nepodporuje, nebo jsou ty vzorce špatně? V obou případech je nemůžete používat. Pravda, jeden rozdíl to je – k formátu ODF můžete vzorce bez problému doplnit a na samotném ODF se nic nezmění. Když budete chtít opravit vzorce v OOXML, musíte vydat nový formát, budou zmatky v tom, která aplikace ve které verzi formátu ukládá…

V OOXML nejsou definovane tak spatne, aby se nedaly vubec pouzivat. S tim malujete certa na zed. A ty zmatky s verzemi budou i u ODF -- realita je totiz takova, ze dnes programatori editoru bez ohledu na ISO implementuji vzorce podle OOo, aby jejich programy vubec nekoho zajimaly. A az vyjde nove ODF se vzorci, ve kterych bude treba neco jinak, bude to uplne stejne, jak to popisujete u OOXML -- jedna banda implementuje "jak to bylo v OOo v dobach ODF 1.0" a druha "nove ODF se vzorci"...

Kdyby šlo o to popsat, jak to dělá OOo, jsou vzorce ve formátu ODF už od začátku.

Nikoliv. Ty vzorce tam nejsou, protoze bylo potreba standardizaci urychlit ze strachu z OOXML.

Jenže formát ODF se od začátku vyvíjí jako formát pro přenositelné dokumenty, a zároveň má být rozšiřitelný na nativní formát kancelářského balíku.

Format ODF byl od sameho zacatku internim formatem OOo a az pozdeji se Sun rozhodl "dotovat" ten format OASISu.

OOo funguje jako referenční implementace – aby se ověřilo, že ten teoretický popis formátu bude v praxi doopravdy fungovat. Samozřejmě že „jak to dělá OOo“ hraje svou roli při vývoji formátu ODF, ale je to pomůcka, ne primární cíl.

To je naivni predstava. Kdyby tomu tak bylo, drzel by se OOo toho formatu, aby to vase "overeni funkcnosti" melo nejakou vypovidaci hodnotu. Status quo je takovy, ze Sun ma s OOo 90% trhu s ODF-compatible editory a specifikaci, podle ktere vystup z OOo uspokojive neotevrete. Myslite, ze je to nahoda?

Naproti tomu Microsoft potřebuje nějaký standard pro svoje dokumenty. Dnes je moderní XML, tak prostě interní reprezentaci dokumentu Wordu místo do binárního formátu nově serializují do XML, a jako standard vydají, co a jak Word serializuje. Vidíte ten rozdíl?

Stejne jako jini v teto diskusi ignorujete vyvoj na poli office baliku za nekolik poslednich let. Microsoft uz si nemuze dovolit tak arogantne obfuskovat, jak to delal drive a jak vsichni tvrdi, ze to bude delat i nadale. Dokazuje to napr. tim, ze investuje do zdroju pro vyvojare pracujici s OOXML. Kdyby chtel lidem co nejvice ztizit cist svuj format, nedaval by do takovych veci prachy.

[Filip Jirsák]

V OOXML nejsou definovane tak spatne, aby se nedaly vubec pouzivat. S tim malujete certa na zed.

Pouze se nedá spolehnout na to, že jiný program vypočte stejný výsledek. Takže pro tak důležité dokumenty, které je potřeba elektronicky podepsat (což jste vytýkal formátu ODF, že tak důležité dokumenty v něm zatím publikovat nelze), je nepoužitelný i formát OOXML.

To je naivni predstava. Kdyby tomu tak bylo, drzel by se OOo toho formatu, aby to vase "overeni funkcnosti" melo nejakou vypovidaci hodnotu.

To je ale pořád dokola. Chápete, že je rozdíl mezi formátem pro výměnu dokumentů (který musí umět nějaký základ), a nativním formátem kancelářského balíku (který musí umět uložit naprosto vše, co v tom kancelářském balíku jde udělat)? OOo „shodou okolností“ používá jako základ pro svůj nativní formát formát ODF, protože ODF takové použití umožňuje – je možné jej rozšiřovat. Úplně stejnou možnost má třeba Microsoft – může ze svých dokumentů exportovat ODF, které půjde otevřít v libovolném jiném editoru podporujícím ODF. Ale bude to jen základ, a když ten dokument otevřete znovu ve Wordu, některé věci nastavené v původním Wordu tam nebudou – protože jsou to věci, které nelze uložit ve formátu ODF bez rozšíření. Nebo může MS zvolit druhou cestu, soubor exportovat do ODF a veškeré věci nad rámec ODF uložit do rozšíření ODF. Pak jiný editor otevře základní ODF, ale pokud ten dokument otevřete znovu ve Wordu, budete mít identický dokument, jako byste dokument uložil v nativním formátu Wordu. Ostatně stejný postup už MS použil dříve – dokumenty z Wordu jste mohl uložit jako HTML, s tím, že do jiných jmenných prostorů se uložily dodatečné informace, ze kterých Word dokázal rekonstruovat komplet původní dokument; zobrazením ve webovém prohlížeči se ukázalo to, co bylo možné reprezentovat pomocí HTML. Taky můžete tvrdit, že HTML dokument vyexportovaný z Wordu neotevřete uspokojivě v jiném prohlížeči, než MS Word nebo MSIE. Ale je to totální nepochopení toho, k čemu slouží přenositelný formát. U HTML dokumentu ocením především to, že si ho můžu otevřít v libovolném webovém prohlížeči a nepotřebuji k tomu Windows a Word. Podobný účel má ODF, akorát nedefinuje základní formát pro jednoduchou prezentaci a výměnu textů (jako HTML), ale definuje formát pro výměnu kancelářských dokumentů.

Stejne jako jini v teto diskusi ignorujete vyvoj na poli office baliku za nekolik poslednich let. Microsoft uz si nemuze dovolit tak arogantne obfuskovat, jak to delal drive a jak vsichni tvrdi, ze to bude delat i nadale. Dokazuje to napr. tim, ze investuje do zdroju pro vyvojare pracujici s OOXML. Kdyby chtel lidem co nejvice ztizit cist svuj format, nedaval by do takovych veci prachy.

Microsoft nechce ostatním ztížit číst svůj formát. Microsoft chce prosadit svůj formát jako standard, a jestli se ten formát někomu čte dobře nebo špatně, to ho nezajímá. ODF bylo od začátku vyvíjeno s ohledem na to, aby jej mohly používat i jiné editory. OOXML je dokumentace interního formátu Microsoftu, a při vývoji toho formátu nikoho nezajímalo, jak se s tím formátem bude pracovat jinému editoru.

Je to stejný rozdíl, jako když se nějaký software vyvíjí od začátku jako opensource, oproti případu, kdy se nějaký software vyvíjí jako uzavřený a teprve dodatečně se rozhodne o jeho otevření. Vždy se pak ukáže, že zdrojový kód není úplně přívětivý pro externí programátory, ale je psán tak, jak to vyhovovalo úzké skupině původních vývojářů. A kód se pak docela dlouho upravuje, aby vyhovoval všem. Často se ten kód na vydání předem ve firmě připravuje (bylo to tak třeba s Interbase nebo naposledy s OpenJDK). Myslíte, že byl formát OOXML nejprve Microsoftem upraven ke zveřejnění, a následně po zveřejnění ještě dlouho doupravován? Asi těžko, kde by na to MS vzal čas. Upravuje se až nyní v rámci standardizace, a to už se jedná pouze o kosmetické úpravy. Srovnejte si to s Geckem, u kterého úprava pro veřejné použití po zveřejnění znamenala napsat ho znova od začátku.

[Daniel Kvasnička ml.]

To je ale pořád dokola.

Jiste, protoze vy tu porad prezentujete striktni teorii a zapominate na to, ze kdyz ma nekdo mezi ODF editory takovy podil jako Sun s OOo, situace se meni. Proste ten podil OOo je tak velky, ze prakticky nema cenu se zabyvat cistym ODF, protoze to skoro nikde nenajdete. Je nutne se bavit o tom, jak rozsifrovat format OOo, protoze ten je relevantni -- at chcete nebo ne -- a ten budete dostavat z verejnopravnich instituci. Vy mi tu vypravite, jak dostanete ODF a otevrete ho jinde a budete tam mit vse dulezite -- ale jak jste na to prisel? Kde berete tu jistotu, ze OOo neuklada do rozsireni mimo ISO ODF nic duleziteho? Uz dnes je jasne, ze tomu tak neni. A do budoucna? Kdo vam to zaruci?

Berme praxi, realnou situaci. Cesko chce kvalitni e-government, zavadi otevrene formaty, tendr vyhraje Sun nebo IBM nebo nekdo podobny s resenim zalozenym na ODF. Tak byste to chtel, ne? Co se bude instalovat na ministerstva? KOffice? Abiword a Gnumeric? (Gnumeric 1.7.8 neni schopen ani poznat, ze bunka v spreadsheetu z OOo 2.2 je formatovana na ceskou menu, udela vam z toho obycejne cislo) OpenOffice.org / StarOffice / Lotus Symphony -- proste neco, u ceho nemate jistotu, ze to do rozsireni mimo ISO standard neulozi nic zasadniho. Takze co musi mit clovek na druhe strane, aby se efektivne branil pred problemy? OOo / derivat. Pokud dojde v soucasne dobe k prechodu na ODF ve statni sprave, dojde v praxi k efektivnimu lock-inu na produkty Sunu a IBM. Lide k tomu budou nuceni proste strachem, ze by to jinde neotevreli tak, jak je potreba -- a u dokumentu ze statni spravy neni dobre podcenovat ani sebemensi moznost, ze by se to stalo. Muze to vyjit draho.

[Filip Jirsák]

kdyz ma nekdo mezi ODF editory takovy podil jako Sun s OOo

Jak je vidět, rozdíl mezi nativním formátem kancelářského balíku a formátem pro přenositelné dokumenty vám stále uniká.

Kde berete tu jistotu, ze OOo neuklada do rozsireni mimo ISO ODF nic duleziteho?

Byl by nesmysl mimo ISO ODF ukládat něco, co je možné uložit přímo do ISO ODF. A do ISO ODF je možné uložit vše, co je pokládáno za důležité z hlediska obsahu dokumentu. Pokud je v obsahu nějaká část, která by mohla být důležitá (např. externí objekt v neznámém formátu), má program možnost uživateli oznámit, že ten objekt nezobrazí – navíc to ale není problém formátu, jakmile umožníte vkládat do dokumentu externí objekty libovolného typu, vždy může software narazit na neznámý typ. Mimochodem, úplně stejný dotaz můžu položit k formátu OOXML – kde berete jistotu, že MS Office neukládá mimo „ISO“ OOXML nic důležitého? Kdo vám to zaručí? A kdo to zaručí u jiných editorů?

Berme praxi, realnou situaci. Cesko chce kvalitni e-government, zavadi otevrene formaty, tendr vyhraje Sun nebo IBM nebo nekdo podobny s resenim zalozenym na ODF. Tak byste to chtel, ne? Co se bude instalovat na ministerstva?

Nechtěl. Já bych chtěl, aby dokumenty na webu ministerstev, které jsou nyní v DOC nebo XLS, byly v ODF. Aby když pošlu úřadu e-mailem v příloze ODF, úřad mi to nevrátil s tím, že jim to Word neotevře. Jestli pak budou interně používat OOo, MS Office s pluginem na import/export ODF, nebo jestli jim něco zpracuje rovnou informační systém, to je mi jedno.

[Daniel Kvasnička ml.]

kdyz ma nekdo mezi ODF editory takovy podil jako Sun s OOo

Jak je vidět, rozdíl mezi nativním formátem kancelářského balíku a formátem pro přenositelné dokumenty vám stále uniká.

A vy se porad tak krecovite drzite svych hezkych, i kdyz pro praxi irelevantnich teorii. Porad si predstavujete, ze statni sprava bude na web davat ODFka, u kterych bude jista interoperabilita a u kterych si budete moci byt jisty, ze vsechny relevantni informace z nich dostanete. Jenze to je za dnesnich podminek nemozne.

Byl by nesmysl mimo ISO ODF ukládat něco, co je možné uložit přímo do ISO ODF.

Ano, ale vas problem je, ze z me neznamych duvodu ocekavate od OOo, ze se timto bude ridit OpenOffice.org je pod faktickou kontrolou Sunu a pro nej je IMHO z business hlediska vyhodnejsi se timto neridit, resp. nekontrolovat nejak konkretne, ze se to deje. Zajisti si tim totiz jeste vetsi rozsireni sveho kanc. SW.

Mimochodem, úplně stejný dotaz můžu položit k formátu OOXML – kde berete jistotu, že MS Office neukládá mimo „ISO“ OOXML nic důležitého?

Jistejsi jsem si uz jen proto, ze specifikace OOXML pokryva mnohem sirsi oblast funkcionality nez ODF. Jiste, ze to MS muze udelat taky, ale u OpenOffice.org je z ciste statistickeho hlediska mnohem vetsi sance, ze se k tomuto bude muset uchylit. Tedy ne proto, ze by Sun chtel zlobit, ale proste proto, ze ISO ODF to nezvladne.

OOXML a vystup z Office 07 byl v ramci kampani jeho odpurcu podroben opravdu dukladnemu a hnidopisskemu zkoumani a me ted vlastne napada, ze je to dobre. U ODF teprve casem zacneme zjistovat, na co "se melo tehdy prijit".

[Filip Jirsák]

A vy se porad tak krecovite drzite svych hezkych, i kdyz pro praxi irelevantnich teorii. Porad si predstavujete, ze statni sprava bude na web davat ODFka, u kterych bude jista interoperabilita a u kterych si budete moci byt jisty, ze vsechny relevantni informace z nich dostanete. Jenze to je za dnesnich podminek nemozne.

Až mi ukážete takový dokument vygenerovaný OOo, můžeme se o tom bavit dál. Do té doby to budu považovat za pouhou ničím nepodloženou teorii.

Ano, ale vas problem je, ze z me neznamych duvodu ocekavate od OOo, ze se timto bude ridit OpenOffice.org je pod faktickou kontrolou Sunu a pro nej je IMHO z business hlediska vyhodnejsi se timto neridit, resp. nekontrolovat nejak konkretne, ze se to deje. Zajisti si tim totiz jeste vetsi rozsireni sveho kanc. SW.

Opět, to samé může udělat MS. OOXML může umět uložit třeba hodinky s vodotryskem, a stejně nic nebrání MS uložit v OOXML textový dokument, ve kterém bude napsáno „Tento dokument byl vytvořen v kancelářském balíku MS Office 2009. Váš editor nepodporuje všechny možnosti tohoto dokumentu, prosím, otevřete dokument v aplikaci MS Office 2009“. A vedle bude jako rozšíření přibalen binární DOC. Jestli má větší páky tohle dělat Sun nebo Microsoft se snad zřejmé, ostatně Microsoft zrovna na poli kancelářských balíků podobné věci praktikoval až donedávna. Naštěstí je teď situace taková, že už si něco takového v oblasti kancelářský balíků nemůže dovolit nikdo, ani Microsoft.

[Daniel Kvasnička ml.]

Až mi ukážete takový dokument vygenerovaný OOo, můžeme se o tom bavit dál. Do té doby to budu považovat za pouhou ničím nepodloženou teorii.

Ja tuhle teorii podkladam tou spoustou veci, ktere nejsou v ODF zdokumentovane, ale OOo (coz by s 99% pravdepodobnosti byl nasazeny software) je produkuje. Ale mozna par pokusu s OOo udelam.

Naštěstí je teď situace taková, že už si něco takového v oblasti kancelářský balíků nemůže dovolit nikdo, ani Microsoft.

Takze vo co gou? Kdyz si to nemuze dovolit ani MS, tak proc nepouzit jeho format, kdyz je lepe zdokumentovany a schopnejsi?

[Filip Jirsák]

Takze vo co gou? Kdyz si to nemuze dovolit ani MS, tak proc nepouzit jeho format, kdyz je lepe zdokumentovany a schopnejsi?

S tím „lépe zdokumentovaný“ bych polemizoval. Tagy jako autoSpaceLikeWord95 asi nebudou v té dokumentaci úplný úlet od jinak vzorné dokumentace, spíš bych tipoval, že je to jenom extrém, ale bude tam spousta dalších jenom o něco méně špatně zdokumentovaných věci. A schopnější? Spíš komplexnější, ne? Což je právě otázka, jestli je to výhoda. Jednodušší věci se zpravidla lépe implementují, implementací je víc, jsou méně náchylné k chybám.

[Daniel Kvasnička ml.]

S tím „lépe zdokumentovaný“ bych polemizoval. Tagy jako autoSpaceLikeWord95 asi nebudou v té dokumentaci úplný úlet od jinak vzorné dokumentace

Ale tyhle veci, i kdyz jsou to humusy, tam alespon zdokumentovane jsou. Kdezto OOo uklada do souboru podobne veci, ke kterym dokumentaci nenajdete nikde (http://www.abclinuxu.cz/forum/show/205203#29). A nez mi budete zase rikat, ze nevidim ten rozdil, tak si uvedomte, ze vystup z OOo je to, co je relevantni. Ne teorie o ISO ODF, ktere dnes prakticky zadny existujici editor nema na svem vystupu a ktere by rozhodne nezacalo kolovat, kdyby se vlady rozhodly "ODF" implementovat.

Navic, tyhle veci existuji jen docasne. Opravdu hodne pochybuji, ze byste je nasel v novych dokumentech, existuji pro zachovani kompatibility starych dokumentu.

[Filip Jirsák]

OOo takhle neukládá věci podstatné pro obsah dokumentu – když z toho dokumentu uděláte čisté ODF, to podstatné vám z toho zůstane. Jak ze stejného OOXML uděláte „čisté OOXML“, když nic takového neexistuje? Jak se autoři různých programů vůbec shodnou na tom, co je „čisté OOXML“, když jako standard je definováno „komplexní OOXML“?

[Daniel Kvasnička ml.]

Jak ze stejného OOXML uděláte „čisté OOXML“, když nic takového neexistuje? Jak se autoři různých programů vůbec shodnou na tom, co je „čisté OOXML“, když jako standard je definováno „komplexní OOXML“?

Pokud vim, ty veci byly vycleneny mimo a nejsou soucasti standardu. Ale zaroven jsou popsany. Chapete? Zadna povinnost, ale moznost nahlednout, kdyz je potreba parsovat legacy dokument. U Sunu nikoliv.

Navic si myslim, ze jsou to veci vetsinou tykajici se formatovani dokumentu a jejich neimplementovani nevyusti ve ztratu dat.

[happy barney]

ale, ale, s fanatizmom to už trochu prehánate. btw, v ooxml bude nový tag, <format-65535-as-100000/>, skvelé, nie ? Veď je to iba formátovanie, nespôsobí stratu dát.

[happy barney]

Jednodušší věci se zpravidla lépe implementují, implementací je víc, jsou méně náchylné k chybám.

+1, s poznámkou: bezchybný software je nepriateľ biznisu

[petr_p]

A vy se porad tak krecovite drzite svych hezkych, i kdyz pro praxi irelevantnich teorii. Porad si predstavujete, ze statni sprava bude na web davat ODFka, u kterych bude jista interoperabilita a u kterych si budete moci byt jisty, ze vsechny relevantni informace z nich dostanete. Jenze to je za dnesnich podminek nemozne.

Jenže to je práve smysl otevřeného standardizovaného a závazného formátu.

V opačném případě se státní správa i standardizační komise mohou jít vycpat.

[happy barney]

keby ľudstvo ako vy, tak (hoci pochybujem, že by sa až tam dostalo) by stále jazdilo na koňoch, pretože tie priblblé autá sa nevedia ani samé napásť.

[Daniel Kvasnička ml.]

Tak tohle je sprostota nejvetsiho kalibru.

Kosek myslim svym dlouhodobym pristupem k OOXML dokazal, ze neni zadny jednostranne zaujaty clovek (na rozdil od drtive vetsiny open source komunity). Kdyz bylo technicky neprijatelne, odmitl ho, kdyz dospelo, akceptuje ho.

[Kyosuke]

Chhm. Vždyť OOXML dodnes nesplňuje ani tu nejzákladnější premisu XML. Nechápu, jak by mohlo být přijatelné v podrobnějších aspektech. Jistě, to není "technický problém", ale prakticky tentýž charakter má microsoftí přístup ke standardizaci. Odpovědět na otázku, proč OOXML definuje pojmenované barvy jinak než zaběhlé standardy, a ještě dvěma různými jmény na různých místech, tím, že "neexistuje žádný explicitní ISO standard pro definování barevných typů. Některé další specifikace mohou definovat barvy, ale jejich cílem je definice pro účely dané specifikace, nikoliv definování obecného standardu pro barvy. Nejde tedy o konflikt se žádným existujícím standardem..." je podle mě od MS docela silný kafe. To je jako kdyby řekli "nebojte, kontrolovali jsme si to a můžeme si udělat vlastní barvy po svém, tak co chcete?"

Člověk by řekl, že i pokud něco není vynuceno, bude se snažit táhnout za jeden provaz z ostatními už jen proto, že to je smysl celé téhle šaškárny. Nevím, jak moc kdo hodnotí nebo nehodnotí současný stav OOXML, ale takovéhle věci mi připomínají ty malé fracky, co se chovají stylem "budu dělat naschvály aspoň v té míře, v jaké mi to projde". Osobně mám dojem, že připomínky odstranily pouze fatální chyby, ale už ne velmi vážné nedostatky, které se radši spousta lidí neopovážila vznést, protože MS by řekl "to je sporné, my si to tak udělat můžeme a zakázat nám to nemůžete". Za takových okolností zůstává standardizační proces i nadále šaškárnou.

[Daniel Kvasnička ml.]

Chhm. Vždyť OOXML dodnes nesplňuje ani tu nejzákladnější premisu XML.

Jako? Pokud myslite binarni data v OOXML, tak ti prectete toto: http://ooxmlhoaxes.blogspot.com/2007/03/ooxml-hoax-7-binary-blob.html

[Kyosuke]

Mám na mysli to, jak je jeden ze základních návrhových cílů XML popsaný větou "XML documents should be human-legible and reasonably clear" elegantně naplněn kódem typu

<w:p>
 <w:r>
  <w:t>This is a </w:t>

 </w:r>
 <w:r>
  <w:rPr>
   <w:b />
  </w:rPr>
  <w:t>very basic</w:t>

 </w:r>
 <w:r>
  <w:t> document </w:t>
 </w:r>
...
</w:p>

[Daniel Kvasnička ml.]

I kdyby ty tagy byly ja nevim jak ukecane, stejne specifikaci budete muset otevrit. Navic ta pismena nejsou nijak nahodne zvolena, maji vztah k tomu, co reprezentuji a nestoji moc usili zjistit, o co jde (ovsem pokud nekoho uprimne zajima pochopit OOXML a nesnazi se ho jen za kazdou cenu shazovat). Ja jsem s tim u XLSX nemel problem. Naopak, mel jsem problem vyznat se v extremne nahustenem a preplacanem ODS, do ktereho se uzivatelsky definovane styly ukladaji do stejneho souboru jako data -- to je reasonably clear? Nejde jen o vizualni vzhled, jde i o navrh.

[happy barney]

nesnažte sa tu obhajovať "worse is better", windows a php už tomuto svetu stačili

[Láďa]

Finta je v tom, že Jiří Kosek hodnotí technickou stránku specifikace a vstřícný/nevstřícný nehraje v tomhle rozhodování roli, důležité je kvalitní/nekvalitní. Ostatně proto byl první hlas NE.

[D-Evil]

Ano, to je super, říct "Tenhle člověk mě zklamal, protože si nemyslí to, co já". Zkoušel jste pátrat po tom, proč má vstřícný postoj? A zkoušel jste se zamyslet, proč ho vy nemáte?

[Ilfirin]

Zbytečná práce

Jinak já se svým odporem k OpenXML netajím, ale chápu pana Koska. Mě kdyby také zpracovali přes 90% připomínek, také bych ten formát přijal.

[Dejv]

jsem se mylil. Akorat nevim, jestli v OOXML nebo v panu Koskovi...

Vazeny D-Evile, tady nejsi na zive.cz, kde je zvykem precis nadpis a maximalne polovinu clanku a pak v diskusi nadavat na neco, co v clanku neni. Nikde v mem prispevku nepadlo ani slovo o tom, ze by me p. Kosek zklamal.

Ja mam ke snaham o ISO standardizaci OOXML odmitavy postoj hlavne proto, ze proste Microsoftu neverim, ze bude tento standard dodrzovat. Ale je to muj nazor a p. Kosek ma plne pravo na odlisny nazor (navic verim, ze asi kvalitnejsi, podlozeny studiem dokumentace).

Dejv

[Mandarinka]

No, tohle jsme tu čekali :) Když OOXML ne, tak to byl pan Kosek hrdina, a moudrý člověk a tak déle... Teď ani nezapochbujete, jestli třeba ta fatva na MSoftí formát není přes míru; prostě začnete s tou starou písničku, že čert ví, kdo ho platí, mě se zdál divnej, asi bude blbej...

Jako sorry, že pořád kritizuju tu linuxáckou mentalitu (taky je mi to už blý), ale docela mi leze na nervy, když se lidi takhle chovaj... když kašlou na realitu, radši si stavěj vzdušný zámky a pěstují nenávist k "třídnímu nepříteli" nebo opovrženíhodné "untertechnologii".

[Dušan]

Ale, ale - tu vôbec nejde o pána Koška. Tu ide o to, že Microsoft proste potrebuje svoj open formát stoj čo stoj. Vieš prečo? Dajme si taký príklad. OOXML sa stane ISO, všetci výrobcovia ho svedomito a presne podľa pokynov naimplementuju, ale M$ zrobí čo? Sk..vi implementaciu vlasneho formatu aby bol s originalom viac menej nekompatibilny. A čo s tým dosiahne? Nejaký úradníček si povie - sakra - ten dobrý M$ sa podujal, že zrobí niečo open, vyhodil na to prachy ale aj tak mi to v tom blbom openoffice nejde poriadne otvoriť - je to nejaké rozhádzané. Tak to je čo sa shit?! Veď určite musí by vina na strane openoffice, keď OOXML je od M$ tak predsa oni musia najlepšie vedieť, že ako ho implementovať, takže u nich problém byť nemôže. Nasrať na openoffice. A všetko pojde v starých koľajách. M$ bude mať monopol - odobrený takými geniálnymi ľuďmi ako je pán Košek, ...

A len tak pre zaujímavosť - prečo vlastne nechce ODF? Lebo je nekvalitný, na figu, ... ??? Ani náhodou. Presne z opačnej strany - v tomto prípade by si nemohol dovoliť dodrbať implementáciu, lebo keby sa nejakému úradničkovi neotvoril dokument v M$ office písaný v openoffice tak by si jednoznačne povedal - nasrať na M$ office keď ani nevedia poriadne otvoriť štandard. A to by bol malý začiatok konca monopolu.

Takže M$ bude mať niečo open - jasajme - ale minca má 2 strany. A tou druhou je to, že ten formát bude tak isto uzavretý ako aj predošlie - a my sa môžeme ísť pásť. Aj vďaka takým geniálnym ľudom ako je pán Košek - sorry ale na dosť veľa vecí sa proste nemožno pozerať len z čisto technického hľadiska - toť môj názor.

[mibo]

+1

[Martin Beránek]

Problémem už nyní je, že současný návrh OOXML není to samé, co je implementované v Office 2007 - a kdy vyjdou nové office? Microsoft svůj formát hnedle zase nezmění. Na druhou stranu nevěřím tomu, že by Microsfot naschvál neimplementoval ISO - leda tak využije současné situace.

Na druhou stranu buďme upřímní- ODF také není bez chyb a dokonalé.

[Filip Jirsák]

Problémem už nyní je, že současný návrh OOXML není to samé, co je implementované v Office 2007 - a kdy vyjdou nové office?

Když můžou v nějakém servicepacku odstranit podporu x formátů, nebude pro ně jistě problém tam podporu jednoho formátu přidat. A u MS by museli být blbí, aby ten schválený formát jako defaultní do svých aplikací netlačili – bude to standardizovaný formát, a k tomu, jak pracují s dokumenty interně aplikace MS Office má tenhle formát bezkonkurenčně nejblíž, takže to pro MS pořád bude znamenat něco při ukládání a načítání lehce poupravit, ale nebude muset dělat žádnou konverzi „logiky práce s dokumentem“.

[egg]

Jmenuje se Kosek. Žádná diakritika.

[Daniel Kvasnička ml.]

Ty z celeho sveta delas nesamostatne kripliky a uvadis ten nejcernejsi mozny scenar. Ja si myslim, ze Microsoft si uz ted nemuze dovolit neimplementovat OOXML, pokud bude ISO. Sun a IBM mu dychaji na zada vic, nez cekal -- mj proto se vubec rozhodli prijit s vlastnim formatem.

[Dušan]

No - sorry - ale kde som napísal, že M$ neimplementuje OOXML (hlavne keď je to jeho formát)? Ja som len napísal, že popis implementácie v ISO je jedná vec a jeho vlastná implementácia v M$ Office bude vec druhá. Proste sami dodrbú vlastný štandard aby nebol neboli komatibilný s konkurenciou a tým ju vlastne eliminujú. Viď kauza JAVA. Tá bola tiež defakto štandard. Ale oni to "dodrbali" podľa svojho a nakoniec bol najhorší SUN lebo ani poriadne nevie implementovať svoj výtvor.

[Mandarinka]

MS by si implementováním cizího formátu nadělal spoustu problémů, kterým se vyhne, když si udělá formát vlastní. Nebude muset obcházet cizí chyby, řešit problémy, které někdo jiný nedomyslel, i když měl. Atd. Ono to dává rozum i z praktického hledisky, nejen z toho špianvě-konkurenčního. To jen tak pro úplnost.

[Luboš Doležel (Doli)]

Ještě že se tak nechovají všechny firmy, to by pak měl každý software vlastní formáty.

[Mandarinka]

To jo.

[vain]

Jako sorry, že pořád kritizuju tu linuxáckou mentalitu

Jaká linuxácká mentalita, snad pár jedinců ne? Taky neříkám že windowsácká mentalita se pořád sere do opensource a mele kraviny jen protože to dělá jedno pako jménem hulda a vy.

[Jiří (BoodOk) Kadeřávek]

Takhle se vyjadřují jedinci, jejichž mentalita je: "já mezi ně nepatřím". Proto se musí vždy vymezit. Linuxáci, češi, politici, feministi, homosexuálové, ... Že je silně zavádějící spojovat jakýkoliv způsob uvažování s barvou, operačním systémem, národností, pohlavím je většinou ani nenapadne.

[Zdenek]

S dovolenim ja bych se tedy take vymezil. Jsem debil a jsem na to hrdy!

OOXML a ODF nejsou jako normy na trubky nebo rohliky, kde lze presne urcit kvalitu. U tak komplexnich formatu se tezko da predstavit plne popsani. To se rovnou jako norma muze zverejnit urcita implementace a basta. Plna prenositelnost je svaty gral informatiky a je nedosazitelna pri zachovani heterogenity software.

[Mandarinka]

Sorry, mezi linuxáky se počítám. Proto mě štve, když z nás - jako z druhu - některé naše exempláře dělají idioty :)

[Dejv]

jsem se mylil. Akorat nevim, jestli v OOXML nebo v panu Koskovi...

Vazeny/a Mandarinko, tady nejsi na zive.cz, kde je zvykem precis nadpis a maximalne polovinu clanku a pak v diskusi nadavat na neco, co v clanku neni. Nikde v mem prispevku nepadlo ani slovo o tom, ze by me p. Kosek zklamal.

Ja mam ke snaham o ISO standardizaci OOXML odmitavy postoj hlavne proto, ze proste Microsoftu neverim, ze bude tento standard dodrzovat. Ale je to muj nazor a p. Kosek ma plne pravo na odlisny nazor (navic verim, ze asi kvalitnejsi, podlozeny studiem dokumentace).

Dejv

[Mandarinka]

Měl jsem na mysli příspěvky, ne článek - ale obojí jsem četl. O nějakém zklamávání ani slovo. Mluvil jsem o tomhle: pro některé lidi z naší operačněsystémové kliky je důležité zničit MS (když to chci shrnout do dvou slov), a nic jiného (třeba kvalita dotyčných formátů, jejich přínosy/problémy v budoucnu). Neberou ohled na skutečný stav věcí, nýbrž se pohybují ve vlastním, do jisté míry vykonstruovaném (cokoliv od MS musí být nekvalitní; cokoliv od MS musí mít v skrytu nějaký nekalý cíl)... A to mi vadí. Já vím, že furt proti něčemu remcat je pro ostatní otravné. Jenže zase moc nemám rád diskuse, kde se někdo nekontrolovaně v podstatě pomlouvá.

[Mandarinka]

Abych k tomu ještě dodal: když se zabývám nějakým sporem, musím k hodnému (linux) i ke grázlovi (MS) přistupovat rovně a nezaujatě (příslovečný spravedlivý proces). Když už toho nejsme schopní, tak aspoň k těm dětem (formátům). Nedávejme jim vinu za hříchy* otců :)

* (ale ani protekci - otevřenost ze SW šmejdského kvalitní SW neudělá)

[Sešívaný]

Jaké jsou podmínky pro změnění z podmínečného ano na ano? Přijde mi to nějaké vágní. Když jsou stanoveny nějaké podmínky, tak by měly být splněny ze 100%. Pokud byl určitý počet připomínek a 90% je nevážený podíl, tak se taky může stát, že těch 10% jsou nejzásadnější připomínky, které MS prostě nevyřešil, a přesto získá ISO standard. Doufám, že tomu tak není a OpenXML se opravdu hnulo směrem k otevřenosti a že bude opravdu open. Nakonec nic jiného mi nezbývá

[petr_p]

Další problém je, že vady objevené při prvním šetření zcela přirozeně nemohou být všechny, tudíž opravení těchto nahlášených chyb by nemělo automaticky znamenat přijetí specifikace, ale nové šetření znovu od začátku.

Celou dobu mám pocit, že MS našel slabinu v procedurách ISA a jednoduše jej zahltil. A ISO ve své domýšlivosti raději OXML přijme než, aby přiznalo, že není v jeho silách celou specifikaci regulérně prozkoumat, a pro objemnost ji zamítlo.

[kafa]

Myslím, že si ISO mělo především položit otázku, zda je žádoucí mít dva různé formáty na totéž. Je to asi stejná "výhoda" jako dvojí rozchod kolejí. Nikdo Microsoftu nebrání usilovat o rozšíření formátu ODF o možnosti, které mu chybějí. Ale trucformát neprospěje nikomu. Navíc bych se moc divil, kdyby Microsoft odstranil rozpory s dalšími normami ISO - které by už sami o sobě měly být důvodem k okamžitému zamítnutí. On na ně celá léta dělá dlouhý nos a ISO se pak posadí na zadek?