Vlákno názorů k článku Microsoft získal ISO standard na Open XML od erg - Preci jen, domnivat se, ze MS muze kdokoliv...

Ale ano, o zakaznika tu jde. Ale majorita zakazniku neprofituje z toho, ze by MS Office podporoval ODF, tem je to jedno :-) Ti potrebuji, aby kdyz otevrou dokument z 7 let stareho wordu, tak aby s nim mohli pracovat a kdyz ho ulozi v formatu noveho, tak aby se jim cely dokument nerozbil... To je to, co potrebuje vetsina zakazniku MS Office - podpora open formatu je jim naprosto ukradena... A MS to chape.

A diky externim tlakum se podarilo tento format standardizovat a mit k nemu specifikaci. Coz je jednoznacne pozitivum pro tvurce a uzivatele alternatich kancelarskych baliku (ala OOo). Tak proc ten flame? Cela leta se nadavalo na MS, ze nezverejnuje specifikace svych formatu, ted to delat zacal, tak v cem je problem?

Pochopte, ze univerzalni reseni v podobe jednoho spolecneho formatu je dost krkolomne, ba skoro nemozne. Mnozstvi dostupnych souborovych formatu toho budiz dukazem.. A formaty jako HTML/CSS nejsou dukazem toho, ze to jde, to je spis odstrasujici priklad.

>Většina výrobců počítačů si až do začátku 80. let také myslela, že jejich zákazníci nebudou profitovat z možnosti libovolně měnit součásti počítače a vyráběli monolitické molochy byť s tehdy velkým výkonem. Pak přišla IBM sice s mizerným hardware, ale se stavebnicovou architekturou, a všem ostatním výrobcům vytřela zrak. A ještě ke všemu dala všechny specifikace volně do světa a ani nic nepatentovala. Důsledek? Po 20 letech bylo 95% všech počítačů typu IBM PC.

A proto neustale narusta trh s hernimi konzolemi, ze :-))

Nicmene tvrzeni, ze za uspechem IBM PC stalo zrovna to, ze se jednalo o modularni architekturu, je docela odvazne. Ale budiz, i kdyz to prijmeme, tak nakup modularniho PC od renomovane znacky je pro zakaznika zarukou navratnosti teto investice - muze pocitac postupne upgradovat, menit jednotlive komponenty atd.

Coz se rozhodne neda rict o ODF.. ODF v tomhle ohledu zakaznikovi zadnou vyhodu neprinasi (pokud vas nejaka napada, tak sem s ni), je to pouze dalsi z formatu. Co mu prinese ODF oproti OOXML? Nic, jenom horsi kompatibilitu s existujicimi dokumenty a funkcemi jeho kancelarskeho baliku.

Jak ODF, tak OOXML jsou otevrene formaty v tom smyslu, ze je k nim volne k dispozici specifikace. Tudiz kazdy ISV ma moznost vytvorit SW pracujici s kterymkoliv z techto formatu. Z tohoto pohledu jsou oba stejne otevrene pro ISV. Mimochodem, jiste vite, ze ODF je zatizeno patenty Sunu a IBM uplne stejne jako OOXML temi Microsoftu, ze (vsechny strany se velmi podobne zavazaly k nezalovani ISV implementujici ODF/OOXML - nicmene ty patenty tam porad jsou) ?:-)

Takze proc by se MS mel podrizovat ODF? Je to produkt jeho konkurence. Kdezto MS potrebuje format na miru jeho kancelarskeho baliku. Coz je logicke vzhledem k tomu, ze MS Office dominuje trh. Proc by si MS mel chtit omezovat jeho SW moznostmi formatu konkurence?

Pochopte, ze firmy stojici za OOo nejsou zadni samaritani, jsou to komercni subjekty jako kazde jine... Nenechte se zmast tim, ze svuj produkt davaji k dispozici jako open source. To je jen velmi dobre promysleny tah. Stejne jako je OOXML od MS. Svet neni cernobily, uz si to konecne uvedomte, nedeli se na dobre a zle :-)

>Na trhu kancelářských balíků je sice ODF jen další z mnoha formátů, jenže geniální využití může přijít z úplně jiné oblasti. Technicky kvalitní a plně otevřená specifikace formátu má řádově větší šanci umožnit takovou myšlenku realizovat než mizerný formát se spoustou rozšíření zabraňujících kompatibilitě. Když jsou snadno dostupné prostředky na realizaci nápadu, nejspíš ho někdo zrealizuje. Když nejsou, všichni kromě úplných vizionářů ten nápad hned zavrhnou jako pitomost a ztrátu času.

To je nesmysl.. Dominantni format tu mame. A ze neni vubec idealni? No tak to chodi, skoro ve vsem...

>Já nepopírám, že Sun a IBM jsou komerční subjekty, kterým jde především o zisk. Jenže jejich zájem narušit oligopol Microsoftu se zatím shoduje se zájmy trhu a jejich snaha vytlačit uzavřené a pseudootevřené formáty se shoduje s mými zájmy jednak jako daňového poplatníka a jednak jako uživatele, kterému čas od času nějaké ty dokumenty přijdou a potřebuje s nimi něco dělat. Zájem Microsoftu udržet si oligopol pomocí pseudootevřeného formátu je v přímém střetu se všemi těmito zájmy.

Shoduje se zajmy trhu? Ktereho? Kdyby se shodovali se zajmem trhu, tak uz ma OOo ci jiny alternativni kancelarsky balik skutecne vyznamny trzni podil a vytlacuje MS Office.

>Zvláštní. Pořád dokola se setkávám s tím, že diskutující dávají rovnítko mezi formáty a kancelářské balíky nebo mezi trh a uživatele. Otevřený datový formát je u kancelářských balíků předpoklad pro vznik konkurence, která je v zájmu trhu jako celku. Jenže samotná existence otevřeného datového formátu nemusí stačit. Drtivá většina běžných uživatelů o něm buď neví, nebo je technické výhody vůbec nezajímají. Když ho navíc jediný program schopný rozumně otevřít staré dokumenty bez cizích doplňků nepodporuje, šance na rozšíření takového formátu ještě víc klesají.

Hehe.. Vitej v kapitalismu :-)

Kazdopadne by mne zajimalo, cim je ODF otevrenejsi nez OOXML? Tim ze ma open source implementaci? To je prece uplne jedno. Tim, ze si mnoho veci dela "po svem"? Jasne, ale to nema s otevrenosti nic spolecneho a nebrani to implementaci (pouze ji to do jiste miry ztezuje). Takze cim je otevrenejsi? Oba formaty jsou zatizene patenty a jejich implementace je umoznena pouze dohodou o nezalovani implementujicich stran (ktera muze byt pro pristi verze zrusena). Takze v cem je ta vetsi otevrenost? A proc se tak oroduje za ODF a ne treba za CDF, coz je z tohoto pohledu mnohem otevrenejsi format :-))

Jiste, OOXML neni dokonaly format, ODF taky ne. Ale tak to chodi, malokdy se technologie prosadi pro svou "technickou" dokonalost, ale v drtive vetsine z praktickych ci obchodnich duvodu. Co je na tom tak sloziteho na pochopeni?

a, MS Office 2008 XML format NEODPOVIDA OOXML standardu a ma obcas problemy nacist dokumenty "rucne" napsane dle tohoto standardu! Navic v prubehu schvalovani ISO doslo v OOXML k nekterym zmenam, avsak MS nikdy nedekleroval, ze tyto zmeny zpetne (treba v soucasti SP) do MSO zavede!

b, Nazvy tagu NEJSOU jedno! Podivej se treba sem: http://www.robweir.com/blog/2008/03/disharmony-of-ooxml.html - proste na ODF ti staci na interpretaci a renderovani textu jeden "obecny" engine, zatimco u OOXML musis byt "stavovy" (jsem ted v "excel modu" nebo ve "word modu" nebo v "powerpoint modu"? apod.). Ty pismena JSOU vybirana nahodne - neexistuje zadne pravidlo! Pokud by nebyly nahodne, jakto, ze zarovnani doprava je jednou "right" a druhak "r", atribut barvy je jednou "val", "w:val" a "rgb" apod.

Kurňa chlape, ty vážně děláš něco s XML, XHTML?

jak rozluštíš teda tyhle tagy?
<w:jc w:val="right"/>

<a:pPr algn="r"/>

<w:alg t="r"/>

Musíte bejt asi úplnej genius, kterýmu se z jednoho písmenka vynoří celé slovo a ještě si ho s žádným nesplete.

Písmena nejsou asi vybírána náhodně, ale vyznat se v tom je kříž. MS vůbec umí volit názvy, jen co je pravda. Jeho VC++ bylo fakt supr čupr.

Proč jako bagatelizujete takovouhle prasárnu? Vy prostě nemáte argumenty, proč OOXML uznat jako ISO standard a tak jen řeknete, že to není důvod pro nepřijetí. Pro mě je to vážný důvod, protože implementace tohoto standardu je zbytečně obtížná a náchylná na chyby a překlepy.

Nevím proč se navážíte hned do Rob Weir, vy sám nepíšete vůbec objektivně.

Myslíte, že kdyby se mělo jednat o standard barevného označení vodičů, tak by tam taky mohla být písmena jako b, w. Možná, že vy byste raději jahodově červený...

Odpůrci mají těch argumentů dost. Ale bohužel jsou jim k ničemu, když se takto přehlíží. Proč to nezkusíte chápat tak, že při příjímání tohoto standardu mohli dát podmínku, že tagy budou přejmenovány. Byl by to o další krok lepší standard, ne? A takto se to dalo udělat s mnoha výtkami. Teď už s tím pravděpodobně nikdo nic moc nenadělá. Tak jako to bude i s dalšími nedostatky.

No tak to bacha. Ten, kdo musi predkladat argumenty, jste vy. OOXML je predlozeno ke schvaleni jako ISO (bylo) a je ukolem tech, kteri s tim nesouhlasi, aby rekli proc.

Vy jste už někdy schvaloval nějaký ISO standard? Já myslel, že v případě, kdy už podobný standard existuje by měl jeho navrhovatel obhájit například jeho potřebnost. Měl by obhájit, že vytknuté chyby nejsou závažné a podobně. Asi si to pletete s presumpcí neviny, kdy někdo musí dokazovat vinu obviněnému. V tomto případě by totiž měla spíše platit presumpce viny - neboli předpoklad, že ten standard je zbytečný a jeho navrhovatel by měl velmi dobře umět obhájit, že má význam, respektuje existující standardy a dobré zvyky ve všech oblastech, kterých se dotýká - tedy pokud je postaven na XML, měl by respektovat doporučení pro jeho zápis, pokud používá matematické operátory, měl by použít opět standardní zápis, pokud obsahuje matematické funkce, měl by je pojmenovávat jejich dohodnutým názvem atd. Možná je to trochu naivní představa o tvorbě standardu, ale pokud by se takto zodpovědně přistupovalo ke každému z nich, vypadalo by to tady asi trochu jinak. A jak už jsem říkal, nemáte argument, že OOXML je potřebné jako standard. Zatím jsem od vás žádný neslyšel (nečetl)

>Odpůrci mají těch argumentů dost. Ale bohužel jsou jim k ničemu, když se takto přehlíží. Proč to nezkusíte chápat tak, že při příjímání tohoto standardu mohli dát podmínku, že tagy budou přejmenovány. Byl by to o další krok lepší standard, ne? A takto se to dalo udělat s mnoha výtkami. Teď už s tím pravděpodobně nikdo nic moc nenadělá. Tak jako to bude i s dalšími nedostatky.

Byl by to lepsi standard kdyby se na nem mohlo pracovat dalsich 10 let :-)) Takhle to ale nefunguje..

>Vy jste už někdy schvaloval nějaký ISO standard? Já myslel, že v případě, kdy už podobný standard existuje by měl jeho navrhovatel obhájit například jeho potřebnost. Měl by obhájit, že vytknuté chyby nejsou závažné a podobně. Asi si to pletete s presumpcí neviny, kdy někdo musí dokazovat vinu obviněnému. V tomto případě by totiž měla spíše platit presumpce viny - neboli předpoklad, že ten standard je zbytečný a jeho navrhovatel by měl velmi dobře umět obhájit, že má význam, respektuje existující standardy a dobré zvyky ve všech oblastech, kterých se dotýká - tedy pokud je postaven na XML, měl by respektovat doporučení pro jeho zápis, pokud používá matematické operátory, měl by použít opět standardní zápis, pokud obsahuje matematické funkce, měl by je pojmenovávat jejich dohodnutým názvem atd. Možná je to trochu naivní představa o tvorbě standardu, ale pokud by se takto zodpovědně přistupovalo ke každému z nich, vypadalo by to tady asi trochu jinak. A jak už jsem říkal, nemáte argument, že OOXML je potřebné jako standard. Zatím jsem od vás žádný neslyšel (nečetl)

Kdyby to takhle mohlo fungovat, byl bych pro to vsemi deseti.. Ale je to nerealne a utopicke. A proc je OOXML potreba jako standard? Protoze napr. vetsina uzivatelu potrebuje komunikovat, posilat si dokumenty. A tem, kteri pouzivaji alternativni operacni systemy ci kancelarske baliky, nezbyva nic jineho nez poprat se s tim, ze majoritni format takoveto komunikace urcuje majoritni kancelarsky balik. Muzes s tim nesouhlasit, nemusi se ti to libit (a mne se to taky nelibi) - ale takova je realita.

Alternativou neni donuceni komercni firmy k tomu, aby se poskozovala prijimanim (a vylepsovanim) formatu jeji konkurence. Jsou v podstate dve moznosti, bud MS bude pouzivat jeho standardizovany format ,nebo jeho binarni balast (jak to delal doposud). Jakekoliv myslenky pro prijeti ODF jsou zcestne...

Navic, co poskytuje ODF za tak velke vyhody? Specifikace je v mnoho ohledech nekomplentni ci nedokonala (ma pouze jine chyby a nedokonalosti nez OOXML - idealni ci dokonaly rozhodne neni zadny z nich), je zatizena patenty stejne jako OOXML atd.

Navic, uz konecne pochopte, ze tohle neni strategie opirajici se o technicke vyhody, ale o obchodni (v cemz neni nic v neporadku - konec koncu cilem kazde firmy je prece generovani zisku). A Sun s IBM v forme ODF nedelaji nic jineho...

Navic, uz konecne pochopte, ze tohle neni strategie opirajici se o technicke vyhody, ale o obchodni (v cemz neni nic v neporadku - konec koncu cilem kazde firmy je prece generovani zisku). A Sun s IBM v forme ODF nedelaji nic jineho...

Já to samozřejmě chápu. Ale vy jste nepochopil asi jednu základní věc. K tomu OOXML kroku MS (téměř jistě) donutily myšlenky EU a dalších států mimo EU o otevřených formátech pro komunikaci s úřady. Uvědomte si, že pokud by EU striktně nařídila, že veškerá komunikace musí být v otevřených formátech, pak by byl MS nucen nějakým způsobem implementovat standard (a nejspíš by to bylo právě to ODF). A pak byste možná i viděl, jak moc by se najednou snažilo ho vylepšovat a že by to celé šlo. Ono by to totiž muselo jít, protože jinak by MS Office mohl snadno skončit v propadlišti dějin. Kde vidíte tu utopii? Přijdou vám utopické poplatky u lékaře? :)

Mas zajimavou predstavu o svobodnem(a volnem) trhu. Narizovani pouziti formatu konkurence, to je opravdu pekne :-))

Opravdu by mne zajimalo, jak si to predstavujes. Ze MS, Sun a IBM zasednou k jednomu stolu a budou debatovat nad nejlepsim moznym formatem? :-))))

Nastesti je to totalni utopie. Takhle silena neni ani EU :-)

Svobodný a volný trh funguje (a ne úplně vždy) jen v případě, že existuje dostatečně silná konkurence. Navíc obvykle nevede k řešením a produktům, které jsou kvalitní, ale spíše levné (nebo obstojí v poměru cena/výkon).

Totální utopie je myšlenka, že trh je všespasitelný. A když jste u toho svobodného trhu - některé praktiky MS nemají se svobodným trhem nic společného.

Kde vlastně vidíte to nařizování formátu konkurence? EU by pouze nařídila, že formát musí splňovat ISO standard + další podmínky. Nikde by netvrdila že všichni musí použít ODF.
Trochu se rozhlédněte kolem sebe a podívejte se jak volný trh řeší všechno.

pak nevim kde berete tu implikaci, ze kdyby EU naridila strktni pouzivani otevrenych formatu, musel by MS s nekym spolupracovat na ODF nebo ho dokonce pouzivat aby neskoncil v propadlisti dejin...

Psal jsem toto: (a nejspíš by to bylo právě to ODF) Což není implikace. Vyjadřuje to názor, že bez OOXML je to asi tak nejvhodnější kandidát na výměnu dokumentů s úřady.

Kolik firem instalujicich OOo se nekdy prihlasilo do vyberoveho rizeni na kancelarsky balik pro statni spravu? Neni to nahodou tak, ze tu vsichni sedime, nadavame, jak je to tam vsechno jen o MS, ale nikdo nehne zadkem aby udelal vlade alespon nabidku?....

To nevím, kolik jich to udělalo. Z rozumového hlediska by ovšem bylo nejvýhodnější používat pouze 1 formát ve všech státech EU. Ono by to mohlo klidně vypadat tak, že se udělá něco jako výběrové řízení na formát.

A stejně tak se měl posuzovat OOXML bez spěchu ;) Komu by mohlo vadit, že by byl standardizován až za 3 roky, když by existovala předverze specifikace. Implementovat by mohl každý.

OOXML je otevreny format

Chyběla mi tam vsuvka - který je standardizován (která tedy po jisté události stejně ztratila význam)

navrhujete snad, aby EU naridila dvema konkurencnim firmam, ze musi pouzivat tentyz format

Ne, konečně už pochopte, že pouze navrhuji, aby EU nařídila formát pro komunikaci s úřady. A takové nařízení je v dnešním světě velice potřebné.

Neslo by to a EU to vi a takovou silenost proste nenaridi.

Kde berete tu jistotu, že by něco nešlo. Dobrá, současný ODF standard má problémy, ale pracuje se na jeho doplnění. Nevidím žádný problém v tom, aby se do ODF přidaly věci, které chybí pro naplnění všech potřebných funkcí, které vyžaduje komunikace s úřady. Ale to přeci neznamená, že ODF by muselo pokrýt celé MS Office.

OOXML musi byt standardizovano proto, ze tak jako tak bude nejrozsirenejsim formatem kancelarskych dokumentu a je lepsi ho mit pod kridly ISO nez jen v ECMA, kde by si s nim MS mohl delat cokoli by chtel. Mozna vam to pripadne jako prilis pragmaticky duvod, ale takova je realita.

MS si se svým formátem může pořád dělat co chce. To že jedna z verzí toho formátu má nyní ISO standard neznamená nic kromě toho, že má nyní OOXML štempl, že je to standardní formát. A věta o tom, že něco musí být standardizováno jen proto, že je to nejrozšířenější je úplně mimo mísu. Podobný přístup pouze nahrává mafiánským praktikám. Když má někdo dostatečné množství financí, umí si získat na současném trhu významnou část zákazníků. Standardy tu mají být proto, aby se celý svět dokázal na něčem shodnout a někam se tak mohl posunout. Jestli vám podobné věty přijdou jako utopie, pak žádný standard nepotřebujete a můžete se vrátit klidně k reverse engineeringu a dále směrem k opicím. Když budete schvalovat standard pro zásuvky, také raději schválíte ten, který vede k bezpečnějším zásuvkám než ten, který je v současné době nejrozšířenější. Zase mi namítnete, že ODF nejsou bezpečnější zásuvky, ale tohle mi vůbec nezkoušejte podsunout. To, že v současné době nemáme ty bezpečnější zásuvky vůbec neznamená, že máme jako standard přijmout ty zásuvky, které v současné době máme.

A co se stane, až OOXML zcela vytlačí ODF z trhu? Pak už nebude žádná hrozba a budeme tam, co jsme byli.

Možná, že pro uživatele to jedno je, ale já jsem také programátor. A tomu by to jedno být nemělo (pokud není lhostejný makáč za prachy, kterému je jedno co a jak vyplodí, hlavně když to bude za kolik).

Formát, který používá MS není v žádných rukou ISO.

>A co se stane, až OOXML zcela vytlačí ODF z trhu? Pak už nebude žádná hrozba a budeme tam, co jsme byli.

No a? Tak prijde neco lepsiho nez ODF. I kdyz uprimne pochybuji, ze by OOXML jakkoliv ohrozovalo pozice ODF, v dusledku je z toho zase jenom soubor kancelarskych baliku (MS Office vs OOo) a jejich nativnich formatu.

Ale popravde, i kdyby byl nativni format OOo OOXML (misto ODF), tak by mi mi tu vubec nevadilo. Ale k tomu samozrejme nedojde, hraci stojici za ODF maji naprosto stejne duvody pro obavy z prilisne zavislosti na OOXML jako ma MS u ODF. Oba formaty si v tomto ohledu jsou velice podobne...

>Možná, že pro uživatele to jedno je, ale já jsem také programátor. A tomu by to jedno být nemělo (pokud není lhostejný makáč za prachy, kterému je jedno co a jak vyplodí, hlavně když to bude za kolik).

:-))) Tak proti gustu... Osobne, ja radsi ty penize nez nesmyslny boj s vetrnymi mlyny :-))

a jak by tak mohlo odpovidat ms office 2008 standardu, kdyz vyslo pred timto standardem? A zde si myslim, ze MS skutecne format dodrzi, nebo alespon bude v teto prijate verzi podporovat...

S temi nazvy tagu, mas pravdu, jedno to neni... Na druhou stranu to neni neco, co by snizovalo funkcnost formatu jakymkoliv zpusobem...

ODF je velmi nedokonaly standard, ktery obsahuje spoustu chyb a nedodelku, navic je navrzen pro uplne jinou aplikaci a chte nechte pro potreby MS Office je nedostatecny... A MS jako komercni firma potrebuje format, ktery bude co nejvice zachovavat zpetnou kompatibilitu s existujicimi dokumenty, coz vyzaduje format prizpusobeny na miru jejich SW... Lamat na tohle ODF by bylo skoro nemozne, navic by se ODF musel vyrazne rozsirit a prepracovat - a na tom MS nema zadny zajem (coz je jiste velmi prekvapive zjisteni, ze).

Jak mohlo MSO odpovidat standardu pred standardem? No treba tak, ze by MSO odpovidalo DRAFTU, ktery samotny MS navrhl! A to neodpovidalo! Nicmene to znaci, ze dneska neni ZADNY SW, ktery by podporoval OOXML.

Nazvy tagu - to teda snizuje funkcnost velmi. Nevim, jestli jsi nekdy programoval neco vetsiho, ale prave tyhle veci maji VELKY dopad na spolehlivost - proste musis neustale davat bacha na ruzne podminky, coz velmi zvysuje komplexitu kodu a pocet bugu/KLOC.

ODF nedokonaly format - muzes byt konkretni? Bez faktu je to jenom FUD! Totez - jak to, ze by bylo nemozne jej upravit a bylo by nutne jej prepracovat. To je preci totalni kravina! Dneska klidne otevres v OO dokument ve Wordu a ulozis jej do ODF, maximalne s minimalni zmenou vzhledu. To preci musi znamenat, ze "vyjadrovaci sila" ODF a OOXML je podobna!

Nemluve o tom, ze spravny pristup by byl, kdyby MS prisel a rekl "tohle a tohle nam v ODF chybi, pojdme vytvorit novou verzi" (na ktere se mimochodem pracuje). Jenze to by tam neprotlacil takove veci, jako "radku jako Word 97".

>Jak mohlo MSO odpovidat standardu pred standardem? No treba tak, ze by MSO odpovidalo DRAFTU, ktery samotny MS navrhl! A to neodpovidalo! Nicmene to znaci, ze dneska neni ZADNY SW, ktery by podporoval OOXML.

No a? To stejne plati o OOo a ODF, ktere zrovna standardu taktez neodpovida v jeho implementaci (nehlede na to, ze v standardu spousta naprosto klicovych veci chybi)

>ODF nedokonaly format - muzes byt konkretni? Bez faktu je to jenom FUD! Totez - jak to, ze by bylo nemozne jej upravit a bylo by nutne jej prepracovat. To je preci totalni kravina! Dneska klidne otevres v OO dokument ve Wordu a ulozis jej do ODF, maximalne s minimalni zmenou vzhledu. To preci musi znamenat, ze "vyjadrovaci sila" ODF a OOXML je podobna!

Jezisi kriste. Jestli je proces otevreni Word dokumentu, tak ja jsem asi jsem slunicko sedmitecny... Vzdyt je to des a bida, vetsinu slozitejsich dokumentu to rozbije. OOo pouzivam uz nekolik let, ale mam kvuli komunikaci s klienty koupenou i verzi MS Office bezici v VMWare. Proc? Protoze znacna cast dokumentu z MS Office se v OOo zobrazi spatne... Word je jeste jakz takz pouzitelny, tam se povetsinou rozhodi jenom pozice, vlozene objekty atd. Nicmene export z Excelu, to je primo katastrofa...

Co se tyka nedokonalosti ODF, tak napr. chybejici specifikace pro tabulkovy procesor (funkce, to bude opravovat nova verze), chybejici specifikace makro jazyka atd.

Navic, kdyz si pustis vedle sebe posledni verzi MS Office a OOo, pripadne ti, ze umi alespon priblizne to stejne? Mne tedy rozhodne ne...

>Nemluve o tom, ze spravny pristup by byl, kdyby MS prisel a rekl "tohle a tohle nam v ODF chybi, pojdme vytvorit novou verzi" (na ktere se mimochodem pracuje). Jenze to by tam neprotlacil takove veci, jako "radku jako Word 97".

A proc by to delal? Proc by si nechal mluvit do svych formatu? Je to komercni firma, ne charita. Navic firma drzici majoritu trhu s kancelarskymi baliky, tak proc by se mela domlouvat s mene uspesnou konkurenci na formatu? Jasne, da se tady mluvit o monopolu, nicmene v pripade otevrene specifikace ma kazdy moznost se poprat s timto formatem nejrozsirenejsiho kancelarskeho baliku...

To stejne plati i o tom obligatnim word97 modu. MS chce zachovavat s svymi formaty zpetnou kompatibilitu - a to je naprosto v poradku, protoze to je to, co po nem chteji (a ocekavaji) jeho zakaznici...

Pochopte uz konecne, ze cilem tohodle tohoto kroku neni vytvorit idealni format pro dokumenty, ale ze se jedna o promysleny obchodni tah. Stejne jako to plati pro IBM a Sun v pripade ODF. Jsou to vsechno komercni subjekty. Co je na tom tak nepochopitelneho, ze tyto subjekty nechcou spolupracovat na jednom formatu, kdyz jsou si vzajemne konkurenci?

Prestante byt naivni....

Zakladni rozpor je v tom, ze kazdy pochopi, kdyz MS vyuzije svuj format k "svetove nadvlade". To, co ale hromade lidi na OOXML vadi, je to, kdyz k tomu zneuziva statni ISO institut, ktery byl prave zavaden k tomu, aby vznikly "vendor-neutral" standardy umoznujici snadnou spolupraci mezi firmami.

>Nazvy tagu - to teda snizuje funkcnost velmi. Nevim, jestli jsi nekdy programoval neco vetsiho, ale prave tyhle veci maji VELKY dopad na spolehlivost - proste musis neustale davat bacha na ruzne podminky, coz velmi zvysuje komplexitu kodu a pocet bugu/KLOC.

Nicmene na tohle jeste musim zareagovat, protoze to je opravdu perla :)) Pokud jako programator mas problem pouze s pojmenovanim tagu, tak to asi o leccem svedci...

Tak ci tak je to problem pouze tvuj, jako programatora a firmy, co vyviji sw kompatibilni OpenXML. Uzivatele to nezajima. A pokud to nezvladnes ty, zvladne to nekdo jiny, cimz ziska konkurencni vyhodu pred tebou... Jak jednoduche, ze?

A jestli jsem neco programoval vetsiho? Pokud povazujes projekty o rozsahu nekolika desitek ci set tisic radku kodu za vetsi, tak asi ano, to je muj denni chleba :))

>Kolik z těch projektů implementovalo nějaký složitý datový formát nebo protokol? Programovat od nuly je vždycky daleko jednodušší, než začít implementovat cizí specifikaci. Zvlášť když ta specifikace není jednoznačná nebo si dokonce někde protiřečí.

Mockrat :-) A mockrat jsem i takove protokoly reverse engineeroval (zvlast u embedded zarizeni) a pak pro ne psal konvertor/emulator...

>Uživatele by to mělo zajímat především. Implementovat jednu věc zbytečně několikrát chvíli trvá. Čas jsou navíc peníze a v tomto případě jeho peníze.

Tohle jsou zanedbatelne naklady oproti cene vyvoje produktu jako takoveho...Je to o prioritach a o tom, co chceme podporovat (jak ODF, tak OOXML jsou na implementaci dost komplexni - ale nemusime je implementovat cele).. Tohle je argument jako kritizovat existenci IPSec proto, ze existuje OpenVPN ktere ma mnohem jednodussi protokol a nastaveni :))

embedded zarizeni a projekty se stotisící řádkami? heh nooooo to čumíím

Jak to myslíte, že nemusíme implementovat celé OOXML. Pochopím jen v případě, že chcete ukládat něco malého do OOXML, kde si sám stanovíte, jak se to uloží. Ale jakmile načítáte OOXML, tak nemůžete implementovat jen půlku.

To je jako udělat zásuvku s jedním vodičem.

Například v případě, že chci načíst jen čistý text stačí následující: program zkontroluje "formátovací úsek", a když nepůjde o označení odstavce, formáty zahodí. V opačném případě přidá znak konce řádku. Ve výsledku získám čistý, neformátovaný text. Postupně si pak svůj iportní program rozšířím například o tučné písmo kurzívu... Obdobně pracují importy u DTP programů, které také neimplementují celý vstupní formát.

To je ale veliké zjednodušení nějakého úkolu. Ale jak říkáte, postupně svůj program rozšířím a zase rozšířím a zase ...
Každé rozšíření musí však respektovat ten formát, takže postupně implementujete více a více standardu. Navíc u OOXML zvlášť pro Excel, Word. Kdyby byly tyto 2 druhy uložené do stejné struktury, měl byste jen polovinu práce.

K čemu je mi dnes vytažení čistého textu z formátovaného souboru? Je rok 2008, obvykle chci při importu získat co nejvíc hotového a ne si to znovu formátovat sám.

U sazby je často jednodušší vzít čistý text, než přeformátovávat to, co zákazník dodal. A stejně se postupuje i v případě ODF. Do importu zahrnu jen funkce, které potřebuji.
Jinak jsem ale jen reagoval na vaše tvrzení, že musíte implementovat celou normu.
A ještě poznámka - u OOXML mohu použít, při nenainstalované MS office 2000-2007, zdarma šířené prohlížeče od MS. Tím mám pokryto prohlížení a tisk u 90-95% trhu. Při potřebě prohlížení a tisku ODF musím nainstalovat OOo. Zde ale dojde k automatickému přiřazení formátů DOC, XLS na tento balík, což v případě již nainstalované konkurence od MS dělá uživatelům nepříjemné problémy.

Trochu se tu míchají hrušky s jablky.

U sazby je často jednodušší vzít čistý text, než přeformátovávat to, co zákazník dodal. A stejně se postupuje i v případě ODF. Do importu zahrnu jen funkce, které potřebuji.

Sazba je specifický úkon, kde vás mnohdy skutečně zajímá jen text, protože formátování, které vám dodá zákazník je typograficky zcela nesprávné. Ale pokud zákazník přijde, že to chce mít všechno rozvrženo tak jak to má on a všechno stejnými fonty, číslováním stránek a podobně, pouze bude chtít něco drobného od vás někde dodělat, pak tohle řešení kapku selže. A dnes je zákazník mnohdy docela pán. Každopádně OOXML nemá být standard, který umožní snadnou extrakci neformátovaného textu. Má to být standard na ukládání editovatelných dokumentů - čili jeho otevření má umožnit provedení změn a následné opětovné uložení ve stejném formátu.

A ještě poznámka - u OOXML mohu použít, při nenainstalované MS office 2000-2007, zdarma šířené prohlížeče od MS.

Supported Operating Systems: Windows 2000 Service Pack 4; Windows Server 2003; Windows XP Tyto OS jsou podporovány pro vámi zmíněný prohlížeč dokumentů. Nějak nevidím Linux, FreeBSD a další a další operační systémy. Když nepočítám, že bych to spouštěl přes Wine, jak si asi tak prohlédnu ten pěkný dokument?

Tím mám pokryto prohlížení a tisk u 90-95% trhu.

Pokryl jste prohlížení a tisk na MS Windows. Nechci si kupovat windows, proto abych si mohl prohlédnout dokument. Jak pokryjete editaci?

Při potřebě prohlížení a tisku ODF musím nainstalovat OOo. Zde ale dojde k automatickému přiřazení formátů DOC, XLS na tento balík, což v případě již nainstalované konkurence od MS dělá uživatelům nepříjemné problémy.

Nemusíte používat jen OO, jak už tu bylo určitě někde zmíněno, ODF se dá otevřít i v KOffice a předpokládám že i v dalších. Joo, že MS nebyl schopen implemtovat načítání tohoto standardního formátu do svého "nejnadupanějšího" editoru pro textové dokumenty, to si ale musíte stěžovat u MS. Asociaci formátů k nějakému programu bych skoro raději nekomentoval - mně se na linuxu žádná neprovede a na windows jí můžete snadno změnit. Pokud se OO při své instalaci neptají, zda chcete asociovat soubory s tímto programem (a nevím jestli to tak je, protože windows nemám), pak je to chybka instalátoru OO. Slušně vychovaná aplikace byt to měla při své instalaci udělat. Každopádně nepleťte ODF a instalátor OO do jednoho koše. Pokud se nemýlím, MS Office při své instalaci provedou asociaci také automaticky a na nic se neptají.

Jako programatorovi je mne pochopitelne celkem jedno, jak se tagy jmenuji (i kdyz s rozumnym pojmenovanim se to lip ladi a je to taky XML best practies). Jestli mam v kodu "const ALIGN_RIGHT='right'" nebo "const ALIGN_RIGHT='asdf'", je mne jedno. Ale neni mne uz jedno, kdyz mam "ALIGN_RIGHT_WORD, ALIGN_RIGH_EXCEL, ALIGN_RIGH_PP" apod.

Nemluvil jsem jenom o programatorem 3rd party firem, pisicich utility pro OOXML. Jde i o programatory v MS, kde pak je stabilita MSO nutne horsi. Je na tom krasne videt nejspise vertikalni cleneni tymu v MS (Word-tym, Excel-tym apod.), namisto horizontalniho (text-render-team, makro-lang-team apod.) - coz vede k znovuvymysleni kola (a pokazde s jinou sadou bugu ;-))

Psat od nuly je sice zpocatku snazsi, ale zase vymyslis casto kolo. Pouzit cizi knihovnu casto znamena se trochu zamyslet a i trochu zmenit svuj styl prace, ale pri dobre volbe "partneru" se to casto vyplati.

Jste normální magor. Programátor může mít problemý s jednopísmenými názvy tagů. Každý dobrý programátor také pojmenovává proměnné smysluplně, tak, aby se v jeho kódu vyznal i někdo další.

Samozřejmě, že to je hlavně problém pro programátory, co budou vyvýjet sw kompatibilní s OOXML. Uživatele to ovlivní z hlediska spolehlivosti naprogramovaného řešení. Nevidím však žádný důvod, proč příjímat standard týkající se IT, který zbytečně ztěžuje programovou implementaci.

Jestli je tohle váš způsob práce nad kódem s takovým rozsahem, nedostal byste u mě ani suchej chleba.

>Samozřejmě, že to je hlavně problém pro programátory, co budou vyvýjet sw kompatibilní s OOXML. Uživatele to ovlivní z hlediska spolehlivosti naprogramovaného řešení. Nevidím však žádný důvod, proč příjímat standard týkající se IT, který zbytečně ztěžuje programovou implementaci.

Ony se IT standardy prijimaji podle toho, jak jsou snadne na implementaci a ciste podle technickych meritek? To je mi docela novinka :-)

Vidis to strasne jednoduse, jenom z pohledu sveho oboru.. Ale svet je trochu vice slozitejsi :-)

Ony se IT standardy prijimaji podle toho, jak jsou snadne na implementaci a ciste podle technickych meritek? To je mi docela novinka

Nic takového jsem neřekl. Řekl jsem, že tento standard zbytečně ztěžuje programovou iplementaci. Jestli neumíte pochopit ani takto jednoduchou větu, raději už ani nečtěte. A když už jsme u toho, myslím, že při příjímání standardu by se toto hledisko nemělo opomíjet. Zvláště, když přejmenování tagů by byla jednoduchá operace, která nijak nenaruší podstatu dokumentu. Z jakého oboru mám asi vidět IT standard? Mám se na to koukat jako strojař? Jste poněkud mimo.

Jenze ty handlery budou znamenat, ze mas pro zpracovani barvy 3 ruzne handlery. A to je jen drobna ukazka. Kolik takovych dalsich duplicit v standardu je... A proste s poctem radku kodu roste i pocet chyb. To je dokazane desetiletimi praxe.

Pán je chytrý. A co když se objeví chyba v implementaci barev. Pak musíš opravovat všechny handlery. Navíc ty handlery musí nějak reagovat na kontext. Zarovnání celé tabulky vlevo se asi chová jinak než zarovnání textu uvnitř buňky tabulky. Přitom tag na tuto funkčnost může mít naprosto stejný název i atributy.

A nejde o nějaké programování - tam se udělá tabulka názvů a je jedno, jestli je to l, nebo left. Jenže ten program, který načítá tuto strukturu se hůř ladí a hlavně, když je to XML, mělo by být přehledné i pro obyčejný textový editor.

Když jsem dělal export DB schématu do XML, také jsem volil jako názvy tagů: table, column a ne t, c. A víte proč? Protože nejsem debil. Protože si uvědomuju, že až se ztratí veškeré dokumentace a někdo najde jen tenhle soubor, tak bude schopnej jen z obsahu pochopit, jak se data načítají.

S lidmi, přehlížejícími tyto věci jako nepotřebné, se dostanem možná tak do háje. Já si vždycky myslel, že si máme práci postupně ulehčovat. Takhle si ji jen a jen přiděláváme.

No a? To je problem implementatora :-) Bez kvalitniho QA se dnes software delat proste neda...

Navic tahle debata naprosto ztraci svuj zakladni smysl. Co je lepsi - mit v majoritnim kancel. baliku implementovany format popsany otevrenym standardem nebo format, ktery musime reverse engineerovat?

Pro mne, jako uzivatele (a drtivou vetsinou uzivatelu), rozhodne ten format otevreny. Vsak konec koncu OOo bude jiz v verzi 3.0 obsahovat podpor OOXML.


Pochop, ze prinuceni MS k prijmuti ODF je asi tak pravdepodobne, jako konverze majority iracanu na krestanstvi :-)

IIS si můžou vrazit víte kam. Navíc IIS pokud vím až do poslední verze neuměl ani .NET přímo ale přes nějaký filtr nebo tak.

Jak myslíte ten monolitický návrh? Příliš nechápu

IIS by mohl hájit jen manažer (managor - magor) ;) aspoň na tomhle se shodnem ;)

Pokud ODF ty styly uloží do samostatné sekce, pak se mi zdá vše v pořádku. Rozumný XML editor vám umožní vybrat si sekci, která vás zajímá v navigaci strukturou dokumentu. Oddělit podobné věci do samostatného souboru nemusí být tak špatný nápad, ale existuje opačné riziko - podívám se na obsah buňky tabulky -> a ejhle byl použit nějaký styl -> otvírám soubor se stylem...
Chci tím říct, že by v těch dalších souborech mohl být i dobrý guláš. Každopádně tento princip by se dal podlě mě protlačit i do odf a tuším že by se tomu nemusel nikdo moc bránit.

Sdílená data mohou být zajímavá. Smysl spatřuji sice jen v nějakých šablonových textech, ale budiž.

Každopádně když už jste otvíral ODF takto ručně, pořád ty tagy nějak alespoň vypadají. V OOXML sice budu mít trochu lepší rozmístění binárních dat, ale zato čtení toho zbytku bude zase daleko obtížnější.

Přijde mi to jako klasický případ něčeho, o čem se měla vést diskuse, zda to nezařadit do další verze ODF (pokud tam něco takového není ;)). Není na to potřeba nový formát

U ODF byl zatím asi spíše zájem o jeho implementaci, než revizi standardu. Co je v nově připravované verzi vskutku nevím. Já nepopírám, že ODF má své boty. Jak snad najdete v komentáři, který jsem přidával někde v diskusi před pár minutami, jde spíše o to, že standardizovaný formát mohl být mnohem delší dobu bič na MS, aby se svými výtvory udělal něco směrem k otevřenosti. Ten bič jsme teď však ztratili. Jedině, že by EU byla tak tvrdá a udělovala v budoucnosti MS nehorázně velké pokuty za to, že se odchýlili od standardu a přitom tvrdí, že jejich balík implementuje ten standard. Zkuste se na to podívat z tohoto úhlu.

Mimochodem - sám jste uznal, že ty verbose jména nějaká výhoda je. Sice u ODF je podle vás silně poničena zbylým způsobem uložení dat, ale ta věta o výhodě zůstává. Kdyby byl tlak na MS větší, možná by i OOXMl mělo lepší názvy tagů a přitom by zůstala ta (podle vás) lepší struktura.

Otázka je, jestli SC34 přežije středeční demonstraci v Oslu. Byl jsem teď se Stevem Pepperem na večeři a má nachystaná některá celkem vtipná hesla ;-D

Změnu elementů rozhodně nelze očekávat. Navíc SC34 se právě dnes dohodla na finální podobě jazyka DSRL pro přejmenovávání elementů/atributů. Takže počítám, že zlomyslná odpověď od SC34 by byla, že si můžete dokumenty v OOXML psát klidně s českými jmény a pak si v DSRL udělat mapování, které z toho udělá "opravdové" OOXML.

Mimochodem někde jsem viděl že po rozbalení odf vzniká i soubor styles.xml. Skoro bych i tušil, že ODF umí styly uložit jinam ...

To se mi zdá zvláštní. Pokud by tomu tak bylo, bylo by to hloupé, ale jsem líný to hledat ;)

Tedy nevím, jak počítáte, ale mně začínají asi tak ve 25%. Stylů je tam poměrně dost, ale tak příšerné to zase není. Oddělení do zvláštního dokumentu by možná neškodilo. XForms neznám, ale podle obsahu dokumentu mi to nepřišlo jako nic příšerného.
Hlavně jsem se v dokumentu dokázal docela dobře vyznat, i když jsem takto zkoumal ODF téměř poprvé.

Mně se zdály ty formy opravdu celkem v klidu. Byly čitelné. Jestli je v nich nějaký složitější problém v určitých situacích, to nevím.
Já koukal na ten dokument v prohlížeči textu v Midnight Commanderu a ten ukazoval asi 25% (zalamoval řádky)

Každopádně krom těch stylů na začátku jsem byl celkem se vzhledem dokumentu spokojen. Takže pokud by se plácly vedle do souboru, pohodka. A upravit něco takového ve standardu nemůže být vůbec žádný problém.