OpenOffice.org není podle očekávání validní s ODF

Považovat chyby v OpenXML za chyby není možné, protože současná verze Microsoft Office 2007 byla vydána *před* schválením ISO standardu a změnami v něm. Navíc je prý potřeba udělat jen jednu závažnější změnu, pro 100% validitu dokumentu. POkud se to ztrivializuje, tak "chyby" v OpenXML je jedna věc opakovaná 12000x.
V případě OpenOffice.org 2.4 je to docela problém, tento kancelářský balík je pro ODF klíčový, a byl vydán dostatečně dlouho *po* schválení ISO standardu.
Zajímavé bude porovat export z Microsoft Office 2007 do ODF, existují na to zdarma pluginy, paradoxně možná Microsoftí Office bude jediná aplikace, která umí validní ODF :)

Now slightly more awesome!

aha, takze MSO bude jedina aplikace, ktera umi ISO ODF a OOo bude zase jedina aplikace, ktera bude umet ISO OOXML... no... trosku zvlastni :D

Radku Hulane, nebilbni a používej stejný metr. Máš pravdu, že je jasné že O2007 nemůže být kompatibilní s novou definicí OOXML, ale stejně tak je jasné, že ODF1.1 nemůže vyhovět validitě na ODF1.0, protože je jeho rozšířením. Když budeš testovat full featured Off2007 dokument na validitu s Office2000, tak taky neprojde.
Navíc autor testu validace udělal ještě několik dalších chyb.

si kkt!

>paradoxně možná Microsoftí Office bude jediná aplikace, která umí validní ODF
No jo,ale ne oficiálně

to bude nejaky hulanovsky PRko.

Jak je tom OpenXML nevim, ale zde je reakce na uvedeny test http://www.robweir.com/blog/2008/05/odf-validation-for-dummies.html. Ukazuje a vysvetluje ze to je trochu jinak. Soucana verze OpenOffice.org produkuje dokumenty dle ODF 1.1, kdezto test byl provaden proti schematu ODF 1.0. Tedy jeste horsi situace nezli pri testovani OpenXML oproti ISO a ne oproti ECMA.

Přesně tak. Doporučuji všem přečíst a udělat si podle toho obrázek o co tu jde. Jsem zvědavý, zda se tyto protiargumenty objeví také v bleskovce...

Proč? Já bych spíš oba články smazal (jak o OpenXML, tak o ODF), protože mají přibližně stejnou vypovídající hodnotu a Živě.cz si jimi jen honí triko a návštěvnost, resp. prokliky. Všichni normální lidé vědí, že článek o OpenXML byl tragédie právě proto, že bulvarizuje obyčejnou nekompatibilitu, která je navíc logická. A tady přichází něco podobného - nejenže se jednalo o strojový přepis do ODF, ale ještě se porovnávaly (podobně jako u Office) různé verze. Takže Živě.cz by se mělo probudit (stejně tak jako zarytí aktivisté pro- a anti-OpenXML) a začít se konečně bavit konstruktivně.

Lenovo ThinkPad T440s | Nokia Lumia 925 | Xbox One + Xbox 360 + PSone
Lenovo Blog CZ

Živě asi dostalo za první člínek přes držku od MS, takže v rámci "vyváženosti zpravodajství" muselo vydat stejně seriózní článek i o protistraně.

Tie pluginy nie sú moc použiteľné (v mojom prípade).
Jeden slúži iba na importovanie a exportovanie, nie na plnhodnotnú prácu s daný formátom.
Druhý spôsobuje pány MS Officu.

Použít se dají, ale nejsou optimální na běžnou práci. MS Office výrazně postrádá možnost uložit a otevřít dokumenty ODF. Export a import jsou docela neohrabané ...

"Autoři použili k testu !!!stejný dokument!!! jako v případě OOXML, museli jej ale strojově převést do formátu ODF pomocí OpenOffice.org 2.4.0."
Pokud ten dokument byl puvodne v ooXML a pak se prevedl do ODT, tak je pochopitelne ze se tam mohou vyskytnout nesrovnalosti a chyby
OpenOffice.org verze2.4 NEPODPORUJE nativne ooXML, takze to musel prevadet nejaky plugin nebo aplikace treti strany, takze bych rekl ze chyba bude asi zpusobena prevodem formatu nikoli v ooo.
to je stejne stupidni myslenka jako napsat neco v ooo, pak stahnout nejaky plugin do mso nebo pouzit jeden z mnoha internetovych prekladacu, ulozit day dokument v ooxml a pak v nem kontrolovat chyby a davat to za vinu mso
PS : MSO2007 nativne NEPODPORUJE ani export ani import do ODT, tak nemuze umet validni odt, zamysli se co pises

Zadku Lulane, nelzi tady. Tech chyb v MS Office bylo mnohem vic. Opet, znova at tudiz opakovane tady siris svoje nemysly. Navic uplne nesmyslne pouzty dokument ve formatu OpenXML pro testovani kompatibility OO s ODF je donebevolajici zhovadilost.

Mno počkejte - pokud nějaký dokument už v OOo _otevřete_ a pak uložíte od ODF, tak to uložení opravdu má být validní. Prostě to berte tak, že libovolný otevřený dokument uložený do ODF by dopadl stejně. Je jen technický detail, že do stavu "otevřený dokument" se dostal importem z OOXML, test by dopadl stejně i kdyby ten dokument někdo naťukal z klávesnice.

To není pravda. Běžně nevidíte zápis v XML kódu, takže nevidíte do kuchyně. Dám vám příklad. Editor rovnic v Openoffice používá texovský princip zápisu rovnice. To znemaná že neklikáte na znako jako v MS Word, ale píšete něco jako programovacím jazykem a oběvují se znaky v rovnici. Je to rychlejší a efektivnější. Ale teď k tomu co chci říct. Když si takto otevřu Dekumnt z Wordu, zápis "kodu" vypada uplne jinak nez dyz to napisu nativne. A je upln jedno, jestli to ulozim jako ODF. Ten zapis tak zustane, dokud ho neprepisu rucne.

Nemate pravdu. Najcastejsia prejavena chyba vznikla prave tym, ze sa ulozili predtym nacitane data, nespravne zapisany element. Teda OO ich najprv natiahol do pamate, chvylu sa okolo nich hral a potom ich zasa bez zmeny vrazil do suboru.

Aha, takže uživatel openoffice musí mít na paměti, co všechno nemá dělat, aby špatně nenatáhl data? Aby se to správně uložilo? Copy & paste může dělat, aby OOo nenakopnul?

Vy to OO strasne nemate rad, vsak? :)
Ano, uzivatel OO by mal mat na pamati, ze ak don narve nefunkcne udaje, vo vysledku ulozi zas len nefunkcne udaje. Bolo by lepsie ak by taketo data OO vobec neotvoril, alebo by pomocou analyzy mozgovych vln svojho uzivatela vydedukoval, co povodne mali tieto data predstavovat?

>> Vy to OO strasne nemate rad, vsak?
Ne, je mi upřímně šumák. Necítím k němu ani sympatie ani antipatie. Zatím jde mimo můj zájem ale beru ho na vědomí.
>> Ano, uzivatel OO by mal mat na pamati, ze ak don narve nefunkcne udaje, vo vysledku ulozi zas len nefunkcne udaje. Bolo by lepsie ak by taketo data OO vobec neotvoril, alebo by pomocou analyzy mozgovych vln svojho uzivatela vydedukoval, co povodne mali tieto data predstavovat?
To je přeci nesmysl. Když je dokument otevřený, vždy a na 100% se musí uložit validně. To je věc ukládací funkce. Jinak by se mohlo stát právě to, že dostanete dovnitř data špatně anebo že se jakkoliv poškodí (vlivem libovolné funkce, operace, kopírováním) - a že dokument bude nenávratně nekompatibilní. Ukládací funkce ze své podstaty nesmí uložit nesprávná data. Ukládací funkce by radši měla změnit vzhled dokumentu, ale ne vytvářet nekontrolovaný formát.

V tom pripade ani Hitler necitil zadne antipatie vuci jinym rasam .

> To je přeci nesmysl. Když je dokument otevřený, vždy a na 100% se musí uložit validně. To je věc ukládací funkce. Jinak by se mohlo stát právě to, že dostanete dovnitř data špatně anebo že se jakkoliv poškodí (vlivem libovolné funkce, operace, kopírováním) - a že dokument bude nenávratně nekompatibilní.
To je zaujimava teoria... Pozrite sa na to takto:
Ked OO Writer nacitava data, jednoducho prebehne XML subor po pismenkach a do pamate si ulozi jeho strukturu. Pri tom tie data nekontroluje, nieco take by trvalo neskutocne dlho a nemalo to by pren ziaden vyznam.
Potom pride vykreslenie. Writer prebehne celu strukturu a postupne zavola ku kazdemu *znamemu* tagu zodpovedajucu proceduru. A tu je hned prvy pripad, kde by sa mohol stretnut nieco nevalidne, neznamy tag. Mal by taky tag ignorovat? Vyhlasit chybu a skoncit? Alebo ho zahodit? Ignorovanie je najvhodnejsie riesenie, nakolko jeho zahodenim by sa mohli stratit cenne data (ktore Writer spracovat nevie, ale program ktory ich ulozil ano.)
Nu a posledna situacia, pri ktorej moze Writer stretnut nieco nezname je pri samotnom vykreslovani jednotlivch elementov. Ale tu opat nemusi dake tie data naviac vobec riesit. Pri vykreslovani (napriklad) odstavca sa proste pozrie do pola atributov, aku ma hodnotu atribut farba, velkost pisma, riadkovanie, atd, atd a to, ze ma naviac atribut "slniecko_svietilo" s hodnotou "true" si vobec nemusi vsimat. A opat, nema dovod tieto udaje kontrolovat (strata casu) ani odstranovat (cenne data inej aplikacie.)
A samozrejme, pri ukladani sa len struktura ulozena v pamati odpise na disk. Zahadzovat nezname data ani tu nieje nutne.
Takze OO nevalidny subor otvori, OO nevalidny subor ulozi a presne tak nevalidny ho nabuduce otvori znova.
Pretoto nepokladam vlastnost OO nasilim nezvalidifikovat nespravne ulozeny subor za chybu.

Promiňte, ale hledáte krkolomná vysvětlení. Za chvíli mi budete opravdu tvrdit, že OOo dělá chyby protože uživatel přes copy & paste natáhl dovnitř nevalidní data. Nakonec aby si uživatel dával pozor, aby nejezdil myší moc rychle, aby to OOo nemusel převzít nevalidně do paměti, heh?
Hádáme se o kravinách. Ona chyba je stejně jen detailní a nemá moc vliv na reálný stav.
Já si trvám na tom, že při ukládání se nemá brát "nějaký stav paměti" ale že se má ukládat dokument podle formátu (ať už je jakýkoliv). V případě, že se ukládá, jak to nazýváte "stav paměti", pak musí mít aplikace kontroly takové, aby vždy byl stav paměti v pořádku - což je nereálná představa a proto se to řeší až při ukládání.
Jak mimochodem podle Vás funguje ukládání v různých formátech v dialogu Save as? Když se zamyslíte nad tímto, i toto jasně mluví o tom, že se formátuje výstup až při ukládání.
Dál k tomu asi nemá smysl co dál psát - myslím že ti, kteří aspoň trochu vědí o čem to je, mi dají za pravdu. Ostatní pravděpodobně nepřesvědčím - ani ne tak kvůli pravdě/nepravdě, ale kvůli tomu, že jsem v tomto případě v opozici proti OOo.

Nehladam krkolomne vysvetlenia, vysvetlujem ako by to fungovalo, ak by som to programoval ja, a ako to pravdepodobne i funguje, nakolko ste to (vdaka bohu) neprogramoval Vy
A rovnako tak, za predpokladu ze uvazujem rovnako alebo aspon podobne ako programatori OO, pri Save as do ineho formatu sa spusta ina "ukladacia procedura" ako pri Save as do odf. Na to, mimochodom, upozornuje aj to dialogove okno.
Jo a len tak mimochodom, aby ste si nerypal len tak sam, problem s copy-pastou a nespravne spracovanym formatovanim z nej ma prave ten "druhy" kancelarsky balicek.

>> Jo a len tak mimochodom, aby ste si nerypal len tak sam, problem s copy-pastou a nespravne spracovanym formatovanim z nej ma prave ten "druhy" kancelarsky balicek.
Nesprávné zpracování je smutná věc. Nesprávné uložení je ale katastrofa. V tom je ten rozdíl.

Takze, mame to dva (navzajom nesuvisiace) problemy:
- V programe 1 sa pri pouziti ctrl+c, ctr+v z programu 3 rozhodi formatovanie a uzivatel musi casto cely text upravovat rucne. To je smutne.
- V programe 2 sa po otvoreni zle ulozeneho suboru ulozi rovnako zle ulozeny subor. Tento program 2 ho vsak opat otvori. To je katastrofa.
Mali by ste si s tym Vasim nazorom na svet davat pozor. Je tak pokriveny, ze by sa on niekto mohol poranit

Spíš mi tedy vysvětlete, jak obecně v jakémkoliv programu chcete zajistit dodržování formátu souboru, když ne na ukládací funkci?

Budeme aplikovat vasi dedukci: Otestujeme kompatibilitu MS Office s OOXML. Vezmete tedy dokument v ODF strcime ho microsoft Office a pokusime prevest na OOXML. Microsoft Office neumi pracovat otevrit ODF a z toho vyplyva ze se nam nepovadlo jej prevest na OOXMl a z toho vyplyva ze MS-Office neumi pracovat s OOXML. Přijde vám to dostatečně debilní?
Přesně tohle ale tvrdíte!

>> Microsoft Office neumi pracovat otevrit ODF a z toho vyplyva ze se nam nepovadlo jej prevest na OOXMl a z toho vyplyva ze MS-Office neumi pracovat s OOXML. Přijde vám to dostatečně debilní?
Co to melete? Tady jde o to, že byl otevřený dokument v OOo (to, že byl získán převodem z OOXML je nepodstatné!) a že otevřený dokument OOo uložil s chybou proti specifikaci.

Vidim ze jste profesionalni demagog, dovolte mi tedy otazku: studoval jste to za bolsevika nebo ted?

Vy jste skutečně magor. Aneb, když plácnu nějakou ptákovinu, tak už na ní musím trvat.
(smyslem tohoto příspěvku není informační hodnota )

Připojuji se k názoru pana Šilhavého: pokud dokument ukládám pod nějakým formátem, musí dodržet jeho specifikace. A není důležité, že jeho část byla získána importem z nevalidního html, část importem z poškozeného textového dokumentu a část importem z databáze. Pokud program ukládá v nějakém formátu, pak musí dodržet jeho specifikace (formu), byť by obsahem byly jakékoliv nesmysly.

Drtivá většina programů jiný formát nepřevádí. Když už nic jiného nezbývá, tak si vytvoří nějaký kontejner a je hotovo. Inteligentní programátor si totiž uvědomuje, že při naprogramování přeformátování může udělat chyby a tím se mohou z původního formátu ztratit nějaká data. Proto do něj rýpe co nejméně.

>> Drtivá většina programů jiný formát nepřevádí.
Ano, ale v tom případě má data uložit as-is uvnitř nějakého elementu, který je definovaný standardem. Určitě si však nemůže přimyslet vlastní elementy nebo atributy do XML formátu.

"Určitě si však nemůže přimyslet vlastní elementy ..."
Vy toho o XML moc nevíte, že? Lépe řečeno, nevíte o něm nic, že?

Dost na to, abych věděl, jak se má ukládat v takovéto situaci.
Promiňte, na tuto diskusi nemám dost sil. Je zde daný standard do kterého se má ukládat. A pokud to aplikace nedodržuje, dělá ze současné situace ještě větší bordel. (přičemž opět zdůrazňuju, že se bavíme o kravině, v tomto konkrétním případě reálně o nic neběží).

Světe div se, ale můj Excel si uložil soubor a už ho nedokázal otevřít. A ne že by nahlásil, že to nedokáže, ale rovnou se při takovém pokusu zhroutil a musel jsem ho startovat znovu. Když jsem zjistiil, že neotevřitelná je i záloha (excel poctivě ukládal a dělal že je vše OK), tak jsem začal zoufat a myslet, že celodenní práce je ztracena. Ale víte co? Nebyla, stačilo soubor otevvřít pomocí OO.org a uložit zpátky do formátu Excelu a Excel zase se souborem dokázal pracovat.
Závěr? OO.org je někdy kompatibilnější s MS_Office více, než samotný nativní Office.

Proč nebyl k porovníní použit nativní dokument ODF, ale použil se překlad OOXML dokumentu?

Také mě to zaujalo. Řekl bych, že ty chyby v ODF mohli být spíše chybami dotyčného plug-inu pro strojový překlad MSOOXML do ODF a nikoliv důkazem, že OOo produkuje nevalidní ODF. Osobně jsem byl za přijetí MSOOXML, ale tyto testy mi přijdou skutečně podivné... :(

Láska, přátelství a ohleduplnost nejsou jen pouhá slova... | Je na nás, dát jim pravý smysl...

V tomto okamžiku je to IMHO vcelku ještě jedno, protože zatím nenadešel čas pro převod do nových formátů - u velikých úřadů a státních institucí. Až ten čas přijde, bude samozřejmě 100% kompatibilita potřeba, ale bude se brát i ohled na existenci vhodného automatizovaného převodního SW. Formát, který půjde snadněji převést do dalších formátů pak bude mít určitou výhodu. A zde MS zatím silně ztrácí.

To by mě zajímalo, proč si tolik lidí myslí, že úřady a instituce zajímá kompatibilita čehokoliv s čímkoliv. Ta linuxová komunita je fakt naivní.

Naivní jsou lidé, kteří si myslí, že open source je pouze gnu/linux...

A naivni su ludia, ktori si nevidia na koniec nosa, netusia co znamenaju terminy s ktorymi operuju a koli tomu ze nieco postacuje im, musi to stacit vsetkym.

Úřady a vládní instituce by to mělo zajímat na základě existence zákona č. 365/2000 Sb.
Mezi požadavky, které musí splňovat komunikační prostředí informačních systémů veřejné správy patří např.
- interoperabilita (nezávislost na provozní a vývojové platformě IS, nezávislost na produktech jednoho dodavatele, standardní a univerzální formáty přenosu dat)
- soulad s požadavky uživatelů (musí umožňovat vývoj v čase tak, aby v maximální možné míře splňovala měnící se požadavky uživatelů, bude maximálně jednoduchá z důvodu snadného pochopení pro potenciální uživatele VS).

Ale on je anarchista a ti zadne zakony nepotrebuji .

Text titulku "OpenOffice.org není podle očekávání validní s ODF"
znamená, že u OOO se čekala nevalidita pro ODF, což je blbost. Jestli se něco čekalo, tak se čekala validita. Titulek by tedy při překvapující nevaliditě měl znít:
OpenOffice.org není NAVZDORY očekávání validní s ODF
---
A to už vůbec nemluvě o faktu, že validní je, jenom není BOMBEN UND IDIOTEN FEST vůči osobám, které chtějí testovat validitu a dělají to tak, že jen prokazují svoje neznalosti tématiky.

Tento článeček je klasickou ukázkou zaujatého postoje, autor nemá rád Open Office a chce ho pošpinit. Já OO také nepoužívám, nicméně se ho tentokrát musím zastat. Kdyby pan Čížek použil titulek ve stylu "MS Office má velké problémy s validací ODF, Open Office má potíže také", myslím, že by to podstatně lépe vystihovalo podstatu problému. Inu, se serverem ZIVE.cz to jde už delší dobu z kopce, takže bulvárnímu tónu se vlastně ani moc nedivím...

>> Kdyby pan Čížek použil titulek ve stylu "MS Office má velké problémy s validací ODF, Open Office má potíže také", myslím, že by to podstatně lépe vystihovalo podstatu problému.
MSO je kolébkou formátu OOXML. Když neproběhla validace OOXML uloženého v MSO, vyšel tu článek znějící hodně podobně.
OOo je považovaný za baštu formátu ODF a má ODF jako nativní formát. Je tedy naprosto na snadě a bez ukřivdění napsat takovýto článek.
S tím, že oba tyto články jsou bulvární a odborně zcela mimo, s tím souhlasím.

Videl bych to tak, ze cela chyba v pripade ODF zacala uz ve zdrojovem dokumentu. Kdyz Mrkvosofti XML format ma chyby tak se ty same chyby prevedou i do ODF dokumentu, tak se pak autor testu nesmi divit stejneho cisla v poctu chyb v pripade obou dokumentu.