Vlákno názorů ke zprávičce Proč bude český hlas pro OOXML „ano“ od anonym - Několik příkladů z dokumentu brm-zprava.pdf: 1. Dokumenty typu strict...
-
Několik příkladů z dokumentu brm-zprava.pdf:
1. Dokumenty typu strict a transitional - Microsoft může generovat všechny výstupy jako transitional a dohodnuté změny v klidu ignorovat.
2. Lokalizované parametry se používaly již v binárních formátech - toto nás má přesvědčit, že mají být po převodu do OOXML, když je tak snadné je dopočítat pomocí vzorce?
3. Práce s datem - povolené jsou obě varianty; proč se tenhle problém (jako jiné zmíněné) překládá na bedra ostatních?
4. Délkové jednotky - "je možné" používat i absolutní, takže chování bude předvídatelné. Děkujeme pěkně.
5. Další rozhodnutí "v podstatě eliminovalo potřebu escapování" - takže eliminovalo, nebo ne?
6. quickTimeFile je "v podstatě" synonymem videoFile - proč ho tam tedy nechali? Podle mého názoru se tohle ospravedlnit nedá.
7. "můžeme implementaci požadovat při první revizi normy" - to se tedy máte; pak vám třeba někdo vysvětlí, že implementace není možná a bude vymalováno.
8. Usnadnění přechodu na nové jazykové identifikátory - pokud jsou převoditelné jednoznačně, pak nechápu, proč tam ty "legacy" vůbec zůstaly. Pokud ne, jedná se o stejně závažný problém.
Ať se na mě nikdo nezlobí, ale podle mého názoru není odpověď "Ano" ospravedlnitelná. Problémy s roundtrippingem nejsou problém, který by měl standardizační komisi zajímat. Pokud pro návrh budete hlasovat, v mých očích se bude jednat jenom o trapné divadlo. -
anonymníA presne to je duvod, proc rozhodovani o ISO standardech nenechaji lidem jako ty:) Lidem, co si prectou o standardu od Microsoftu na velmi uzitecnych, netendencnich a hlavne velmi objektivnich a informativnich strankach linux.com nebo slashdot a hned se povazuji za nejvetsiho odbornika na dane tema:) Nevim, jestli tyhle nazory naprosto bezvyznamnych jednotlivcu a nymandu jsou k smichu nebo k placi. K smichu je ta nepodlozenost a vychazeni z lzivych a tendencnich clanku a k placi je to, jak se snazi sve "hodnotne" nazory prezentovat v diskuzich, zvlaste pote, kdyz je uz rozhodnuto o standardu, misto aby tak ucinili predtim, kdyz mel kazdy jednotlivec moznost ten standard pripominkovat. Jen muzem dekovat Bohu, ze tam jsou lide z trochu jineho inteligencniho spektra, kteri maji poneti o cem se jedna a kdyz se maji k nejakemu dokumentu vyjadrit, tak si ho alespon prectou a necerpaji o nem sve znalosti z diskuzi na internetu:) Vychazejme tedy ze situace z realneho sveta, Microsoft navrhnul standard, kazdy (tim myslim uplne kazdeho) se k nemu mohl vyjadrit a vznest pripominky, vsechny pripominky byly vzneseny, do pripominek z Ceske strany zahrnuty a dle Koskova vyjadreni byly take vsechny opraveny! Fakt uz nedokazu pochopit, ze se tu jeste najdou individua (nebo spis uplni pitomci!), kterym se porad neco nezda. Vsechny vase jednotlive pripominky, ktere jste meli, byly zjevne opraveny, nezbyva, nez se radovat z toho, ze Microsoft vsechny tyhle hlasy vyslysel a specifikaci OOXML upravil ke spokojenosti nas VSECH!
-
Tobě se můžu leda smát. Já jsem provedl konkrétní analýzu relevantního textu, který nepochází z žádného "FUDistického webu", ale přímo z pera Jiřího Koska. Ty jsi dokázal akorát to, že:
1. Umíš plivat jenom jedovaté sliny, ale konkrétní argumentace Ti je cizí. Až se mi nechce věřit, že něco takového, co tady bliješ, vzniklo v roce 2008 a ne v Biĺakově dílně v dobách Anticharty.
2. Odmítáš číst zcela konkrétní kritiku OOXML (Defective by design) a oháníš se jakousi neprokázanou znalostí specifikace. Myslím, že bys tu specifikaci nedokázal ani dočíst, natož pochopit nebo se k ní dokonce kvalifikovaně vyjádřit.
3. Neumíš používat diakritiku, což je u českého uživatele Windows (jak předpokládám) vážné na pováženou.
4. Porušuješ zásady Netiquette a chováš se jako hulvát - formálně i obsahově.
Že se nedokážeš podepsat ani nickem, je více než logické a je to, paradoxně, na Tvých příspěvcích to nejrozumnější. -
To bych neřekl; chybu může udělat každý - ještě mám blbě toho Biľaka, můžeš mi ho vytknout taky. Ale jak tak koukám na Tvůj příspěvek, tak nečitelnost Tvých textů není jenom věcí chybějící diakritiky, ale též absence interpunkce, počátečních velkých písmen a celkového stylu. Prostě písmenková polévka.
-
Jirka Kosek (neregistrovaný)1. Dokumenty typu strict a transitional - Microsoft může generovat všechny výstupy jako transitional a dohodnuté změny v klidu ignorovat.
Asi jste si neprostudoval dopad změn. Změny přijaté na BRM se týkají strict i transitional dokumentů. Všechny vlastnosti formátu, které jsou potřebné pro věrnou reprezentaci starých dokumentů, jsou nyní součástí pouze strict dokumentů. Co bude dělat MS a jiní implementátoři, je jejich věc. Mohou si vybrat, zda implementují podporu pro strict, transitional nebo obojí.
2. Lokalizované parametry se používaly již v binárních formátech - toto nás má přesvědčit, že mají být po převodu do OOXML, když je tak snadné je dopočítat pomocí vzorce? Asi vám unikl fakt, že onen lokalizovaný parametr nemusí být konstanta, ale výraz, který závisí na jiných buňkách a do těchto buněk může uživatel vkládat údaje, které ovlivní výsledek. Takže při konverzi z binárních formátů nejde tento případ vždy detekovat a nějak elegantně odstranit.
3. Práce s datem - povolené jsou obě varianty; proč se tenhle problém (jako jiné zmíněné) překládá na bedra ostatních?
Protože "chybná" varianta je použita v miliónech existujících dokumentů a nejde ji vždy automaticky detekovat (ze stejného případu jako v předchozím bodě).
4. Délkové jednotky - "je možné" používat i absolutní, takže chování bude předvídatelné. Děkujeme pěkně.
Asi jste si v původním dokumentu s připomínkami zapomněl přečíst důvod této připomínky. Cílem připomínky bylo umožnit použití "normálních" jednotek, pokud někdo generuje OOXML "ručně". Použití jednotek bylo v původní i opravené verzi OOXML zcela jednoznačné, nyní je navíc uživatelsky příjemnější pro ty, kdo budou OOXML generovat z různých aplikací (ručně to asi nikdo psát nebude ;-D).
5. Další rozhodnutí "v podstatě eliminovalo potřebu escapování" - takže eliminovalo, nebo ne?
Ve strict dokumentech escapování nebude potřeba. Navíc vám uniklo, že escapování je popsáno jednoznačně, akorát konkrétní stylistika věty může někdy vyznít ve smyslu, že se escapuje jen první podtžítko v celém řetězci a ne první podtržítko na začátku každé escape sekvence. To je detail, kterých jsou ve stávajících ISO normách tisíce, a snadno se vyjasní během následné údržby normy.
6. quickTimeFile je "v podstatě" synonymem videoFile - proč ho tam tedy nechali? Podle mého názoru se tohle ospravedlnit nedá.
Tak jsou v normě dva elementy, které jsou v podstatě synonyma. No a co. Proč je v HTML element <img> a <applet>, když obrázky i applety lze vkládat pomocí <object>?
7. "můžeme implementaci požadovat při první revizi normy" - to se tedy máte; pak vám třeba někdo vysvětlí, že implementace není možná a bude vymalováno.
Jaký vliv má na technický obsah normy to, zda se nějaká definici opakuje, nebo je uvedena jen jednou a vedou na ní odkazy? Žádný. Jaká má smysl na této změně trvat, když většina účastníků BRM měla opačný názor? Žádný.
8. Usnadnění přechodu na nové jazykové identifikátory - pokud jsou převoditelné jednoznačně, pak nechápu, proč tam ty "legacy" vůbec zůstaly. Pokud ne, jedná se o stejně závažný problém.
Protože "legacy" jazykové kódy mají jemnější členění než BCP-47 kódy, a někteří uživatelé chtějí tyto rozdíly zachovat při round-trippingu dokumentů. (Pokud se nepletu, nenabízí BCP-47 standardní způsob, jak rozlišit mezi tradiční a moderní španělštinou).
Problémy s roundtrippingem nejsou problém, který by měl standardizační komisi zajímat.
Divil byste se, pro kolik uživatelů je roundtripping důležitý (kvůli starým systémům, které umějí jen .doc a je zbytečné investovat do jejich upgrade). Standardizační komisi to musí setsakramentsky zajímat, když je to jeden z cílů normy.
Bohužel problematika dokumentových formátů, OOXML, potřeb uživatelů, kvanta existujících dokumentů atd. není tak jednoduchá, jak se na první pohled zdá. Bohužel mnoho lidí si neuvědomuje platnost jednoduchého motta - "Čím více toho vím, tím více vím, kolik toho nevím." -
Inkvizitor (neregistrovaný)> Co bude dělat MS a jiní implementátoři, je jejich věc.
A já tvrdím, že Microsoft po případném schválení standardu bude tento standard využívat k dalšímu posilování dominantní pozice. Nejde o žádné vytvoření nového, lepšího, otevřeného formátu, ale o prosazení formátu, který bude v plné míře implementovat jenom MS Office - klasická taktika Embrace, Extend, Extinguish. Nevyvrátil jste v zásadě ani jednu námitku. Pokud se přijme nový, otevřený a férový standard, nemají v něm "legacy" fragmenty co dělat. Pokud Microsoft chce skutečně řešit problémy uživatelů, ať je řeší "za své". Sedli jste Microsoftu na lep a přijali jste jejich hru. Hraním si na Sókrata to neomluvíte. -
Jirka Kosek (neregistrovaný)Nevyvrátil jste v zásadě ani jednu námitku. To je váš názor. Podle mne jsem v zásadě vyvrátil všechny vaše námitky, ale chápu, že již podle nicku se na to nedokážete podívat s otevřenou myslí. ;-) Pokud se přijme nový, otevřený a férový standard, nemají v něm "legacy" fragmenty co dělat. Většina stávajících dokumentů tyto legacy prvky používá, bez nich je nejde bezestrátově převést. Možná, že vás zrovna tento problém netrápí, ale pro mnoho uživatelů je důležitý. Proč jim chcete bránit v tom, co potřebují a chtějí? Pokud legacy vlastnosti nepotřebujete, můžete používat OOXML Strict nebo ODF nebo HTML/XHTML nebo třeba plain text. využívat k dalšímu posilování dominantní pozice No upřímně řečeno mysím, že tu současnou pozici už moc posílit nejde, takže OOXML v tomto ohledu žádnou významou roli hrát nebude. Navíc pro konkurenty je mnohem snazší konkurovat v podpoře formátu OOXML než binárních formátů, protože dokumentaci k OOXML lze používat legálně a je asi tak o dva řády lepší než nedávno vydaná dokumentace k bin. formátům.
-
Takže super, dostali jsme se k argumentaci ad personam, ale budiž. Já přece nechci nikomu bránit, aby převáděl do něčeho svoje legacy dokumenty. Ať si je převádějí do čeho chtějí, klidně ať je dál ukládají jako *.doc. Já ale požaduji, aby ty prvky nebyly v ISO. Chci, aby státní instituce a jiné organizace, když zveřejní nějaký dokument pod ISO formátem, aby tyto dokumenty bylo co nejsnáze a jednoznačně zpracovatelné v co nejširší škále programů a když daná instituce zveřejní dokument jiný, aby se nemohla vymlouvat na ISO, ale aby existovala možnost vznést protest a žádat sjednání nápravy. Vaše benevolence je v tomto ohledu jednoznačně kontraproduktivní. Že je OOXML lepší formát než *.doc, je samozřejmě pravda, ale můj názor je, že by standard měl být psán s ohledem k budoucím potřebám a neměl by řešit problémy s převodem dokumentů, které pocházejí z 10 let starých programů.
-
anonymní3. Ak nie je možné automaticky detegovať typ dátumu, program sa musí užívateľa opýtať, ktorý typ dátumu teda v dokumente používa. A to isté môže spraviť aj konvertor na OOXML. Toto je možné aplikovať aj na bod 2.
6. Podľa mňa, img má iný sémantický význam ako object, kdežto quickTimeFile a videoFile sú sémanticky totožné.
8. Je možné sa inšpirovať napríklad objektom Locale v Java http://java.sun.com/j2se/1.4.2/docs/api/java/util/Locale.html, kde je možné vlastnosťou variant rozlišovať medzi tradičnou a modernou španielčinou. Podstatné je, že ďaľšie 2 fieldy obsahujú hodnoty ISO štandardu, konkrétne ISO639 a ISO3166.
> Bohužel problematika dokumentových formátů, OOXML, potřeb uživatelů, kvanta existujících dokumentů atd. není tak jednoduchá, jak se na první pohled zdá. Bohužel mnoho lidí si neuvědomuje platnost jednoduchého motta - "Čím více toho vím, tím více vím, kolik toho nevím."
Ja (a evidentne aj ďaľší ľudia) som si predstavoval ISO štandard ako normu, absolútne nezaťaženú historickými pokusmi a omylmi. Je ešte iná ISO norma definujúca niečo ako prechodný stav (transient - u HTML je podobný mechanizmus, tiež kvôli Microsoftom pokrútenej histórii HTML), alebo OOXML je prvý precedens?
