Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
Kapacita v oboru XML Rick Jellife (standards activist, autor Schematronu a člen ISO SC34) se veřejně postavil proti odporu ve věci standardizace Office Open XML jako ISO formátu. Jeho argumenty si můžete přečíst v blogpostu The anti-OOXML mob need to lift their game.
Tiskni
Sdílej:
Tady nejde o to, že by měnili standard OOXML, ale že by se toho standardu nedrželi. Zkrátka si ten formát budou sami dále rozšiřovat a měnit u sebe (a MS Office by pak mohl defaultně ukádat do "vylepšeného" OOXML, standardizovaný OOXML podle ISO/IEC 29500 by byl jen jako další jiná možnost uložení).A co si myslis, ze dela Sun s OpenOffice? Prosimte, snad nezijes v predstave, ze to, co ti dnesni OOo ulozi je ISO ODF 1.0 a jen a pouze ISO ODF 1.0?
Nevšiml jsem si, že by mi jakákoliv prohlížečka měnila kód stránek a něco si tam svévolně přihazovala (např. element strong přepsala na b a uložila mi to na server).uff, a tuhle pitomost jsi z příspěvku, na který reaguješ, vyvodil jak?
Nepřijetí OOXML za mezinárodní normu tento monopol upevní (věřit tomu, že vlády a velké organizace budou vyžadovat přechod na ODF je naivní představa).Podle mého mínění přijetí OOXML za mezinárodní normu monopol Microsoftu upevní. Věřím, že některé vlády a některé velké organizace budou vyžadovat přechod na ODF a nepokládám to za naivní představu. Ti co budou chtít používat standard a vyžadovat jeho používání, budou muset volit ODF, pokud ovšem ISO neschválí OOXML.
pokud ovšem ISO neschválí OOXMLCož se stane.
když nemá normativně definovanou syntaxi vzorců.Narozdíl od XLS? To s tou syntaxí vzorců v ODF je věc dočasná a navíc v praxi nevadí.
Mluvil jste o Excelových tabulkách. Na tabulkách v OOXML rozhodně žádná ekonomika nestojí.Excelové tabulky lze do OOXML uložit. Vaše předchozí tvrzení:
Ti co budou chtít používat standard a vyžadovat jeho používání, budou muset volit ODF,asi není úplně konzistentní s
V praxi je jedno, že ODF 1.0 nemá specifikaci formulek. Miliony nebo já nevím kolik lidí používá v OpenOffice vzorce. Mají problémy? Většinou ne.Takže je vlastně jedno, že stovky miliónů lidí používají vzorce v MS Office. Mají problémy? Většinou ne.
ODF 1.2 a OpenFormula tento deficit odstraní.Nemyslím, že je reálné, aby se ISO normou staly dříve, než za 2,5 roku.
Excelové tabulky lze do OOXML uložit.Do ODF většinou taky.
...asi není úplně konzistentní s...Jakto? ODF je momentálně jediný ISO standard pro kancelářské dokumenty. Nic jiného není. Takže musí volit ODF, přestože OpenFormula není dokončena a schválena, což není zas takový problém. ODF 1.2 ho odstraní, stejně jako další známé problémy.
Takže je vlastně jedno, že stovky miliónů lidí používají vzorce v MS Office. Mají problémy? Většinou ne.Ono totiž záleží i na jiných věcech než na množství problémů, například na otevřenosti formátu a z toho plynoucí svobodné přenositelnosti dokumentů, tedy informací. Současný stav, kdy lidi používají XLS, DOC a PPT je prostě nevyhovující, a není to kvůli tomu, že by lidi měli s těmito formáty praktické problémy.
Nemyslím, že je reálné, aby se ISO normou staly dříve, než za 2,5 roku.Což je škoda. Doufám, že nemáte pravdu, ale já netuším. Microsoftu (a vy mu v tom pomáháte) se daří ODF sabotovat (pomocí OOXML). Kdybyste se vy a ostatní co pracují OOXML místo té hromady kontraproduktivní práce na formátu, jehož jediným účelem je sloužit Microsoftu a zabít ODF, věnoval ODF 1.2, už bychom třeba měli pokrok. No nic.
Jakto? ODF je momentálně jediný ISO standard pro kancelářské dokumenty. Nic jiného není.Diskuse byla o situaci, která nastane, pokud bude DIS29500 přijat.
informací. Současný stav, kdy lidi používají XLS, DOC a PPT je prostě nevyhovující, a není to kvůli tomu, že by lidi měli s těmito formáty praktické problémy.OOXML je šance, jak se binárních formátů jednou provždy zbavit. Tím formátem mohlo být ODF, ale to by musela být jiná situace na trhu, vývoj ODF by musel být rychlejší a muselo by být později posláno do ISO. Tím, že OASIS poslal funkčně nevyzrálou verzi ODF do ISO, formátu ve výsledku dost uškodil. Měli se zaměřit na rychlejší dokončení verze, která by byla ODF1.2+OpenFormula, a až tu poslat do ISO.
Microsoftu (a vy mu v tom pomáháte) se daří ODF sabotovat (pomocí OOXML).Microsoftu v ničem nepomáhám. Pouze pro ČNI zpracovávám připomínky k jednotlivým standardům, které má na starosti ISO/IEC JTC1/SC34. V této pozici musíte normy posuzovat trošku jinak, než tahle si mi líbí, protože ji udělali správní hoši, a tohle je srágora, protože za ní stojí zlá korporace.
Kdybyste se vy a ostatní co pracují OOXML místo té hromady kontraproduktivní práce na formátu, jehož jediným účelem je sloužit Microsoftu a zabít ODF, věnoval ODF 1.2, už bychom třeba měli pokrok. No nic.Řekl bych, že moje práce na OOXML byla celkem produktivní.
Diskuse byla o situaci, která nastane, pokud bude DIS29500 přijat.Ano, a já se k té situaci vyjádřil odkazem na současnou situaci, kdy nic dalšího přijato není, s přáním aby nebylo. Rozpor v tom co píšu nevidím.
OOXML je šance, jak se binárních formátů jednou provždy zbavit.Fajn. Jenomže to že jsou ty formáty binární není ten hlavní problém. Problém je, že jsou proprietární. Nejsou svobodné. Ano, jsem pro se jich zbavit a nahradit je svobodným formátem. OOXML je odpovědí Microsoftu na takový svobodný formát. Je to prostředek k tomu tento svobodný formát sabotovat a vnutit lidem a organizacím svůj vlastní formát, který svobodný nebude. Nevěřím vám. Nevěřím Microsoftu. Věřím těmto lidem.
Tím formátem mohlo být ODF, ale to by musela být jiná situace na trhu, vývoj ODF by musel být rychlejší a muselo by být později posláno do ISO.Já nevidím problém. ODF svou funkci plní dobře.
Tím, že OASIS poslal funkčně nevyzrálou verzi ODF do ISO, formátu ve výsledku dost uškodil.V čem je nevyzrálá? V tom že nemůžu do prezentace vložit přímo tabulku? Vždyť to lze obejít. ODF 1.0 funguje velmi dobře a ODF 1.2 dořeší jeho nedostatky a tak dále.
Měli se zaměřit na rychlejší dokončení verze, která by byla ODF1.2+OpenFormula, a až tu poslat do ISO.ISO to evidentně nevadilo, protože standard ODF 1.0 byl schválen.
Microsoftu v ničem nepomáhám. Pouze ... blablabla ...No jo, no.
Řekl bych, že moje práce na OOXML byla celkem produktivní.To je jako s revolucí a kontrarevolucí. Co je co?
Když vám tolik na srdci leží budoucnost ODF1.2, proč se jejímu vývoji nevěnujete vy sám?Protože mi na tom srdci neleží zas až tak moc.
A když dovolíte, ve svém volném čase se radši podílím na vývoji pořádných formátů jako je DocBook a souvisejících open-source nástrojů pro jeho zpracování.Tak to je mi sympatické, přestože píšu všechno v LaTeXu.
CIO firmy nebo organizace by musel být hodně zdrogovaný, aby vyžadoval formát ODF, když nemá normativně definovanou syntaxi vzorců.Zrovna u vzorců tabulkového kalkulátoru je syntaxe jenom polovina toho, co je potřeba standardizovat. Ta druhá půlka, stejně významná, je standardizace významu těch vzorců, včetně všech možných okrajových podmínek. Možná se pletu, ale OOXML je v tomto smyslu „standardizován“ spíš tím „jak to dělá Excel“, než že by OOXML standard precizně popisoval výpočty.
SIN(2)
nebo třeba 1+MOD(1,0)
? A podle kterých částí standardu jste k tomu výsledku dospěl?
... již na základní škole se učí ...takže DIS 29500 odkazuje na vzdělávací systém v každém jednotlivém státě, namísto aby specifikovala formát vstupu? - tak to je ještě "lepší" než jsem myslel, kam se hrabe nějaké odkazování na předchozí verze MS Office
Další, co není schopen si přečíst ani odstavec.já si jej přečetl a projistotu jej ocituju, aby bylo jasné, že se bavíme o tomtéž: Funkce SIN - Kapitola 3.17.7.288, Part 4 DIS 29500, již na základní škole se učí, že argument pro goniometrické funkce se zadává v radiánech a numerické metody pro výpočet goniometrických funkcí jsou obecně známe. Pokud je neznáte, doporučuji nějakou pěknou knížku o matematice, třeba od pana Rektoryse. Výsledek je 0,909297427
Kdybyste se do specifikace podíval, tak tam najdete, že argument je v radiánech.to je možné, že bych to tam našel ... otázka ovšem je, jak z ocitovaného odstavce, který si prý nejsem schopen přečíst, toto plyne?
Ono totiž nikoho nenapdalo, že čtenář specifikace nebude mít základní vzdělání v matematice.hm, obávám se, že čtenář specifikace má v matematice mnohem lepší vzdělání než ten "nikdo, koho nenapadlo", neb narozdíl od něj alespoň ví, že je třeba tu jednotku specifikovat (tedy že to vůbec nějakou jednotku má, a že se jich po světě používá více ...)
Funkce SIN - Kapitola 3.17.7.288, Part 4 DIS 29500, již na základní škole se učí, že argument pro goniometrické funkce se zadává v radiánech a numerické metody pro výpočet goniometrických funkcí jsou obecně známe. Pokud je neznáte, doporučuji nějakou pěknou knížku o matematice, třeba od pana Rektoryse. Výsledek je 0,909297427Na základní škole nemají děti o radiánech ani ponětí, takže se vše zadává ve stupních. Pokud ve specifikaci není napsána ani taková věc, jako v jakých jednotkách se zadává parametr funkce, je to specifikace na dvě věci. Od takové specifikace pak těžko můžu očekávat, že bude řešit chybové stavy, okrajové podmínky, nebo dokonce problémy s výpočty v plovoucí řádové čárce a zaokrouhlovací chyby.
Funkce MOD - Kapitola 3.17.7.216, Part 4 DIS 29500, to co jste napsal vrátí syntaktickou chybu. Funkce MOD potřebuje dva argumenty a ty se oddělují středníkem, ne čárkou.Ach jo, překlep. Tak ještě jednou – jaký je dle specifikace výsledek vzorce
1+MOD(1;0)
?
Já jsem si speciifikaci těch dvou funkcí samozřejmě přečetl – a zjistil jsem, že je ta specifikace ještě horší, než jsem si myslel. „Spočítá sinus zadaného argumentu“ není specifikace, ale pohádka na dobrou noc. Když to naimplementuju tak, že argument bude ve stupních, v radiánech nebo v gradech, pořád to vyhovuje specifikaci. Akorát to bude dávat pokaždé jiné výsledky.
Funkce MOD
je ještě lepší – tam je rovnou ve specifikaci napsáno, že výsledek je v některých případech „unspecified“. Takže dvě různé implementace mohou vracet naprosto rozdílný výsledek. Stačí si zjistit, že obchodní partner používá MS Office 2007, který jako výsledek MOD(1;0)
vrátí něco, použít jinou implementaci, která vrátí něco jiného, napsat si příslušný vzoreček do smlouvy a takovou smluvu elektronicky podepsat. Soud pak může udělat jediné – doporučit oběma stranám, aby pro předávání a podepisování dokumentů používali formát, jehož standard zaručuje, že obsah dokumentu bude pokaždé stejný, ať se dokument zobrazí v libovolné implementaci odpovídající standardu.
Takže jsme se dostali znova k tomu, že ODF nespecifikuje vzorce proto, protože napsat dobrý standard pro vzorce tabulkového kalkulátoru není žádná legrace a je na to potřeba čas. MS žádný dobrý standard na vzorce nepotřebuje, ten to má v Excelu nějak naprogramováno a jenom dal k dispozici „standard“, se kterým není Excel v rozporu. Že jenom podle toho standardu není možné napsat implementaci, která by dávala stejné výsledky, jako Excel? Že ten standard nezaručuje, že další verze Excelu nebudou počítat jinak (ale stále v souladu se standardem)? To jsou jenom takové nepodstatné drobnosti…
Akorát to trochu shazuje význam standardů (případně ISO standardů) jako takových. Kdyby ISO standardy za něco stály, můžou se na ně různé instituce a vlády spolehnout. EU nebo vláda by mohla vydat zákon, že státní správa musí přijímat dokumenty ve formátu určeném mezinárodními standardy, a ve vyhlášce se upřesní, že se tím myslí např. standardy ISO. Jenomže pokud bude OOXML schváleno jako ISO standard, bude muset rozumná instituce či vláda tenhle standard explicitně z povolených standardů vyjmout (a zákon zesložitit o formulaci „mezinárodně uznávané standardy, které zaručují stejnou interpretaci datového nosiče nezávisle na použité etchnologii“, nebo něco podobného). Nerozumná vláda či instituce pak bude muset po několika soudních sporech zákon změnit, že pokud jde o něco opravdu důležitého, musí to být stejně na papíře, protože elektronickým dokumentům nelze věřit. A pak se bude několik let zase pracně prosazovat používání elektronických dokumentů a pracně dokazovat, že elektronické dokumenty mohou být bezpečné, pokud se nepoužije jeden špatný standard.
Četl jste ECMA-736, které se u ISO nestandardizuje.Máte pravdu. Četl jsem to, co se dalo o OOXML sehnat. Nicméně zůstávají moje pochybnosti o tom, že lze standard, který původně okrajové podmínky a chyby skoro neřešil, opravit sérií nějakých připomínek. Protože to, jestli píšu návod, jak něco implementovat, nebo píšu něco, čemu má jen vyhovět stávající aplikace, je velice podstatný rozdíl, který se odrazí už v celkové stavbě takového standardu.
sin
pro hodnoty 0, -1 a 1 bude argument chápat jako úhel v radiánech, a pro ostatní jej bude brát ve stupních, vyhovím specifikaci, příklady mi vyjdou správně, ale stejně budu počítat jinak než Excel.
Definici sinu nebo zlomků není potřeba do standardu uvádět, to jsou všeobecně známé věci, které jsou „definovány“ matematikou. Ovšem matematický sinus má jako argument úhel, a úhel znamená číselná hodnota plus jednotka. Pokud chce někdo použít sinus, který bere bezrozměrný argument (číslo bez jednotky), nezbývá než nadefinovat jak se z jeho sinu dostanu ke standardnímu matematickému sinu.
Zbytek po dělení nulou není definovaný, ale ve standardu nemůže být „undefined“, tam musí být nějaký chybový kód. V případě funkcí SIN a MOD to bylo v připomínkovém řízení zřejmě už opraveno. Ovšem pořád mám velké pochybnosti o tom, jestli z původně takhle děravého standardu je možné hektickými připomínkami a přehlasováváním vytvořit úplný standard – tj. takový, podle kterého (tj. pouze dle standardu, odkazovaných standardů a obecně známých skutečností, bez znalosti jiné implementace) bude možné vytvořit impelmentaci, která bude významově kompatibilní s jinými implementacemi – tzn. nejenom to, že dokáže formát z jiné implementace otevřít a uložit, ale že jej bude stejně interpretovat. Protože to je to, co je na standardu pro elektronické dokumenty podstatné.
Dneska si klidně můžete vyměňovat binární doc vytvořený v nějakém ne-MS programu. Ale kde máte zaručeno, že při zkoumání formátu reverzním inženýrstvím nenastala někde chyba, a vám se v ne-MS programu nezobrazuje z docu něco, co je např. součástí historie dokumentu, ale v aktuální verzi to nemá být zobrazeno? Standard pro dokumentové formátu by měl být od toho, aby se tomuhle předešlo – to ale znamená, že třeba u vzorců musí být ten standard napsán tak, že každá implementace standardu dojde ke stejnému výsledku, a zároveň že implementace, která dojde k výsledku jinému, neodpovídá standardu.
Předpoklad, že goniometrické funkce „pracují běžně“ s radiány nemá podle mne v mezinárodním standardu co dělat. Příkaldy jsou hezká věc, ale nejsou normativní – kdybych napsal implementaci tak, že sin
pro hodnoty 0, -1 a 1 bude argument chápat jako úhel v radiánech, a pro ostatní jej bude brát ve stupních, vyhovím specifikaci, příklady mi vyjdou správně, ale stejně budu počítat jinak než Excel.
Promiňte, ale na to nejde napsat nic jiného, než že budete počítat jako debil.
Standardy předpokládají, že máte dobrou vůli je interpretovat. Když tuto vůli nemáte, nepomůže vám nic, vždycky se můžete točit na jednom slovíčku.
Možná by nebylo od věci smířit se s tím, že finální text DIS29500 nebude zase taková sračka, jak se někteří snaží prezentovat, a přestat tady šířit demagogické bludy. Howgh!
Promiňte, ale na to nejde napsat nic jiného, než že budete počítat jako debil. Standardy předpokládají, že máte dobrou vůli je interpretovat. Když tuto vůli nemáte, nepomůže vám nic, vždycky se můžete točit na jednom slovíčku.Otázka je, k čemu má takový standard sloužit. Pokud je takovým standardem HTML, je v pořádku, že standard něco předpokládá, že od implementátora očekává dobrou vůli, že ponechává implementátorovi jistou volnost. Pokud jde o mezinárodní standard pro výměnu dokumentů, který má ambinace prosadit se v oblasti veřejné správy (jinak se nebude Microsoft obtěžovat s ISO standardem – aby si mohly firmy posílat docx mezi sebou, stačil ECMA standard, nebo to jen někde vyvěsit na webu ), nemůže předpokládat od implementátora dobrou vůli, ale naopak zlé úmysly. Protože tam už se dostáváme do oblasti podobné elektronickým podpisům, certifikačním autoritám atd. – a zkuste někomu, kdo se zabývá třeba asymetrickou kryptografií, navrhnout, že ty jejich standardy a protokoly jsou zbytečně složité, a že by se měla taky předpokládat spolupráce a dobrá vůle na straně všech zúčastněných. Od standardu pro výměnu elektronických dokumentů očekávám, že když vytvořím nějaký dokument vyhovující stnadardu a podepíšu ho elektronickým podpisem, každý, kdo ověří můj podpis a zobrazí dokument programem odpovídajícím standardu uvidí ten samý obsah, jako já. A pokud uvidí něco jiného, můžu já nebo ten druhý omlátit výrobci jeho program o hlavu, že odporuje tomu a tomu bodu standardu. S vašim přistupem uvidíme každý něco jiného, a autorovi programu můžeme akorát říci, že počítá jak debil, ale všechno bude v souladu se standardem. Ostatně na to, že všichni věděli, že se vzdálenosti měří v metrické soustavě nebo že se jako oddělovač desetinných míst používá tečka, už dojelo třeba pár vesmírných sond.
Možná by nebylo od věci smířit se s tím, že finální text DIS29500 nebude zase taková sračka, jak se někteří snaží prezentovat, a přestat tady šířit demagogické bludy. Howgh!S tím, že to nebude zase taková sračka, ale jenom sračka, jsem se už smířil. Od ISO standardu bych ale očekával vyšší kvalitu – třeba že by se jeho slovní hodnocení pohybovalo v kladné části spektra, nebo alespoň kolem nuly.
Microsoft samozřejmě může v další verzi office změnit formát, ale proč by to dělal, když by jej to diskvalifikovalo na trzích, které si definují takováto pravidla?Jenže problém je v tom, že Microsoft to může udělat, aniž by se diskvalifikoval. Viz můj příspěvek výše - stačí aby defaultně nové MS Office ukládaly do "vylepšeného" OOXML (uplně to vidím, "Advanced OOXML+ Ultimate Edition"
(věřit tomu, že vlády a velké organizace budou vyžadovat přechod na ODF je naivní představa)Rozhodně si nemyslím, že to je naivní představa. Pokud se nepletu už se tak stalo v jednom státě USA. A nějaké signály v tomto smyslu snad byly i z Dánska (nebo Nizozemska). Nemám teď ale čas to dohledávat a nerad bych mystifikoval (moje paměť má k dokonalosti hodně daleko
věřit tomu, že vlády a velké organizace budou vyžadovat přechod na ODF je naivní představaTo se stalo už v nejednom případě. Takže tomu věřím.
ISO se ukazuje jako neschopné spoluvytvořit a schválit jednotný standard pro kancelářské balíky.A co je jako ODF?
No uvidíme, každopádně schválením dvou relativně podobných standardů namísto jednoho kvalitního....IMHO spíš jde o schválení druhého, méně kvalitního standardu vedle už schváleného relativně kvalitního, který může mít brzo novou verzi, adresující známé nedostatky.
DIS 29500 má nedořešených 13 připomínek.Protože ty zbylé přijali, aniž by je někdo četl, ne?
U MSOOXML (DIS 29500) jsou to tisíce (často se uvádí >3500).Po odstraneni diplikatu to neni ani tretina tebou uvedeneho poctu. Z toho bylo skoro 200 probrano explicitne, neco pres 800 papirovym hlasovanim a 13 zustalo nedoreseno.
Of the 1027 Editor’s responses, the BRM addressed 189 responses by specific resolutions and discussions of the BRM, and the rest using a paper ballot where each National Body in attendance voted: this accepted 825 of the Editor’s recommendations and rejected 13. (The issue of a paper ballot had been abstain on issues of lesser interest to them.Člověče, přečti si to taky.
"Samozřejmě vzhledem k vysokému počtu připomínek (1027 po odstranění duplicit) bylo od začátku jasné, že nebude čas na probrání všech připomínek a návrhů na jejich vypořádání přímo na místě."Říkat teda, že v MSOOXML jak je navržen pro ISO je třináct (nebo šestnáct) nedořešených problémů je zhovadilá pro-MS propaganda.
Jo, myslíJo, myslim. Nepsal jsem svuj nazor na to, psal jsem vysvetleni toho cisla 13, co kolega vyse zminil.
A myslí vůbec?Typicke, na nic vic se nezmuzes.
Samozřejmě vzhledem k vysokému počtu připomínek (1027 po odstranění duplicit) bylo od začátku jasné, že nebude čas na probrání všech připomínek a návrhů na jejich vypořádání přímo na místě.Aha! Kde je teda ten rozpor mezi tím co říkám a tím co říká Jiří Kosek?
Výsledkem hlasování bylo, že z původních návrhů ECMA bylo 1011 přijato pro zapracování do výsledného textu normy a 16 bylo odmítnuto. Z přijatých 1011 návrhů pak bylo během BRM ještě 186 změněno. Z 16 odmítnutých byly dále během BRM změněny 3 návrhy.No vida. Tenhle dokument mi jenom potvrdil co jsem věděl před jeho přečtením (a pár drobností upřesnil). Děkuju, ale odporovat mi touto zprávou nelze.
pro OOXML je fast-track proces zcela nevhodnýProc?
The process was complete, utter, unadulterated bullshit. I’m not an ISO expert, but whatever their “Fast Track” process was designed for, it sure wasn’t this.Jediní, kteří nepochybují, že fast track je MSOOXML to pravé jsou ti co ho chtějí vidět schválený za každou cenu, domnívám se.
Tim Bray ví víc.Hmmm, kde ze to ten pan pracuje? Sun Microsystems. No ten bude asi hodne objektivni... Ta veta, kterou jsi tu ocitoval, nerika vubec nic o tom, proc by fast track mel byt pro OOXML spatny, jen ukazuje, ze pan Bray nejspis nevi, o cem mluvi. Nebo je spis liny si precist direktivy JTC1. Tady se nebavime to tom, jak to nakonec dopadlo. Ja se te ptam, proc je podle tebe fast track proces jako princip spatny pro schvalovani OOXML. Jediny rozdil je v tom, kdo muze posilat pripominky. Takze ukaz na necem, jak se tahle konkretni zmena projevila negativne, ukaz jak by to bylo pozitivni, kdyby slo o PAS proces.
PAS a fast-track jsou shodné procesy, liší se pouze tím, kdo může specifikaci do tohoto procesu poslat. Termíny na hlasování a zasílání připomínek jsou zcela stejné, pravidla pro hlasování také. Stačí si přečíst direktivy JTC1.Je skoda, ze se o tomhle v poslednich par mesicich nemluvilo intenzivneji na verejnosti. Kdyby se vsechny ty zvasty o zrychlenem schvalovani OOXML vytiskly na papir, znicily by desetkrat tolik lesu co specka OOXML...
...Doufám, že schvalování nové verze ODF u ISO bude i u nás veřejné, jako byl proces u OOXML.Těžko říct. Jak jsem se výše dočetl, už teď jsem buď uplacený nebo mdlého ducha. Doslechl jsem se, že root na mne chystá defenestraci. Nevím jestli já nebo někdo jiný bude mít chuť se do toho příště pustit, když pak musí čelit takové typicky české věcné argumentaci podložené argumenty a znalostí tématu
Nehladte vylucne na technicku stranku problemu.ale jo, to klidně může, hledět na to čistě technicky, jenom je potřeba, aby hleděl dál než na špičku svého vlastního nosu ... bohužel tento pán již několikrát dokázal, že toto - patrně zcela účelově - neumí jeho argumentace o "dobré vůli" při implementaci standardů (mimochodem, Filip s tím příkladem z kryptografie výborně kontroval, i když to napsal poněkud krkolomně) je mi vyloženě k smíchu, když si vzpomenu, jak jsem se kdysi začetl do jeho výukových materiálů o psaní www stránek, a zjistil jsem, že co chvíli prosazuje věci, které jsou - alespoň dle mého výkladu - v příkrém rozporu s duchem dotyčných standardů ...