Názory k článku
Proč bude český hlas pro OOXML „ano“
-
anonymníTak tohle je naprosto prelomove rulezni:) Myslim hlavne clanek Koska:) Jak se nakonec ukazalo, tak OOXML je prinosny, je potreba, vsechny nesrovnalosti byly vyreseny a bude schvalen. Je ode me asi nanejvys utopisticke myslet si, ze FUD kolem OOXML utichne a nejvetsi fanaticti rvaci proti OOXML zustanou v diskuznim hrbitove, FUDove clanky na fanatickych serverech se prestanou objevovat a fanatici se zameri na jinou technologii od Microsoftu o ktere nic nevi ... no nezbyva nez doufat, nejspis do dalsiho clanku o OOXML nebo dalsiho prispevku do diskuze:o)
-
Rejpal (neregistrovaný)Schválně, jak by se pan Kosek vyjádřil k tomuhle?
http://www.robweir.com/blog/2008/03/how-many-defects-remain-in-ooxml.html
Nesrozumitelné nebo očividně chybné pasáže, nechráněné přihlašovací údaje do databází, problémy s RTL jazyky... Skvělá práce. ;/ Fakt někdo věří tomu, že specifikace o 7500 stránkách se dá kvalitně zpracovat v zadaném čase? A můj dojem skoro je, že to jsou spíš náhodné poznámky programátorů v MS, než kohezivní a struktruovaný dokument, co nejdřív uvede koncepty, pak představí prvky jazyka a vysvětlí je. Taky by mě zajímalo, co to je ten "spreadsheet server", co to má umět a proč se o tom hovoří v části, která je microsoftí náhradou SVG. Očividně kromě špagetového kódu existuje taky špagetová dokumentace. ;-) -
anonymníNo, realita je takova, ze kazdy nymand co tu na foru prudi z FUDama, ti co pisou podobne nesmyslne clanky jako v tom odkazu, proste vsichni ti nymandi se k tomu mohli vyjadrit, meli dostatek casu si tu specifikaci nastudovat a vznest pripominky. 6000 tisic stranek oproti 4em nebo 5ti co ma ODF neni zas tak moc na specifikaci, pokud to nekdo nepobral, tak ok, ale nechapu, ze se k tomu teda vyjadruje, kdyz o tom nic nevi. Uvedu zjevnou premisu, ktera se od ted stane vseobecne uznavanou pravdou: Jsou dva druhy lidi, ti co OOXML cetli! a rozumi! a ti co tomu vubec nerozumi. Ti co tomu rozumi, tak kdyz nasli neco co jim vadilo, tak to mohli uvest a nejspis i uvedli, jelikoz na to meli dostatek casu a plne pravo. A TI, CO TOMU KUWA NEROZUMI, TAK NEMAJI NEJMENSI PRAVO NA TOM COKOLI KRITIZOVAT NEBO JAKKOLI SE K TOMU VYJADROVAT, PSAT STUPIDNI RADOBY TECHNICKE A OSVETOVE CLANKY A PODOBNE!!! HOWGH!!!
-
Rejpal (neregistrovaný)Zasekl se Vám Caps Lock a <strong> element. ;-) Ne, vážně, ODF opravdu nemá pět tisíc stránek, dokonce nemá ani čtyři tisíce. OOXML četla spousta lidí, a udělala si o tom svůj závěr:
http://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html
http://ooxmlisdefectivebydesign.blogspot.com/2008/02/truth-about-microsoft-office.html
http://ooxmlisdefectivebydesign.blogspot.com/2008/02/typical-bs-in-technical-articles-about.html
http://ooxmlisdefectivebydesign.blogspot.com/2008/03/bad-surprise-in-microsoft-office-binary.html
Tak, jako jsou .DOC a .XLS binární dumpy heapu spuštěných Office (nebo téměř něco takového), tak je OOXML (polo)textovým ekvivalentem téhož. Je to prostě nový formát Microsoft Office, ne výměnný formát na dokumenty. ;-) Naštěstí se mě tyhle spory zas až tolik netýkají, jinak bych se angažoval více, jak nás k tomu nabádáte. -
Sten (neregistrovaný)Mě jako největší problém OOXML přijde snaha nadefinovat si všechno po svém. Proč potom existují standardy pro zápis času nebo pro vektorové obrázky? Jistě, ODF je v tomhle jen o málo lepší, ale když máme jeden špatný standard, nebudeme přeci zavádět druhý špatný standard.
Co se týče českého hlasu: pokud je ten hlas podmíněn něčím, co bylo splněno, pak by samozřejmě měl být ano. Mě ale přijde divné, že se vůbec nějaké OOXML řešilo. Mělo se jednoznačně říct: takový standard již existuje, proč tedy zavádět úplně nový formát? Pokud máte k ODF připomínky, nestačilo by ODF opravit? (stačilo, ale to by nesměl být ten Microsoft, který poslední dobou vymýšlí vlastní standardy místo těch ISO)
Anebo taky byste chtěl přestavovat byt, protože by se změnily rozměry dveří kvůli tomu, že jsou problémy s přiděláním určitého typu kliky? -
Sten (neregistrovaný)
Návrh standardu jsem četl stejně jako FUDovité mezinárodní připomínky a jejich komentáře. Netvrdím, že tomu standardu nějak super rozumím, je to obrovské a já nemám čas se v tom vrtat, ale zkus příště trochu konkretizovat, co je na mém příspěvku špatně, takhle se fakt blbě odpovídá.
- zápis čísel: používá svůj vlastní formát kolidující s Unicode i doporučeními W3C
- vektorová grafika: používá svůj vlastní DrawingML (Transitional dokonce VML) místo SVG
- vzorce: používá svůj vlastní OOML místo MathML
- makra: neobtěžuje se specifikovat jazyk; logické by bylo použít ECMAScript, ale obávám se, že Word bude používat nějaký druh Basicu
Jak jsem psal, podobné problémy má i ODF, ale přeci nebudeme nahrazovat špatný standard jiným podobně špatným.
-
anonymníK tomu bych rekl leda to, ze k tomu asi meli nejaky duvod. Dokumentaci jsem necetl, cetl jsem vzdycky jenom nejake shrnuti od validnich lidi, treba Koska. Vsechny vetsinou spojovalo krome drobnych nedostatku, taky duvod proc tu OOXML je, kdyz je tu ODF a sice to, ze ODF je zastaraly a nevyhovuje narokum MSOffice. K tomu zapisu cisel, ono doporuceni je jedna vec a nejaky standard druha, pokud jim to nevyhovovalo a neni na to standard, tak to udelali tak jak to vyhovovalo jim, pokud popsali jak se to ma zapisovat, nevidim v tom sebemensi problem a pokud nekdo jo, tak to mohl pripominkovat. Vektorova grafika, to same, pochybuju (a dokonce za to dam ruku do ohne), ze existuje nejaky standard. Pokud pouzivaji uz leta nejaky DeawingML a popsali ho, tak zase jako u tech cisel, neni sebemensi duvod ho odmitat. Vzorce to same. Je treba si uvedmit nejzasadnejsi vec na celem OOXML. Tou veci je, ze je to format pro MSOffice, to v prve rade. Nema smysl diskutovat o tom, ze MSOffice je nejpouzivanejsi a zdaleka nejvetsi kancelarsky balik. Rado se to srovnava s OO, ale to co zvlada OO je jen spicka ledovce, proto jiz zmineny fakt, ze ODF na MSO nestaci. Abych neodbihal, OOXML je tu teda pro MSO, je otevreny, je zdokumentovany, navic to bude ISO, takze do nej nebude moct kdokoliv hrabat. To prinasi snad vsechny mozne pozitiva, protoze i kdyz tu je ODF uz dlouho a je to jakymsi standardem, tak realne pouzivani oproti nestandardnimu a nedokumentovanemu DOCu je asi v takovem pomeru jak Lin vs. Win......tudiz nulovy. Tim, ze bude MSO pouzivat otevreny format, tak je to jen dobre, pokud by ISO neproslo, naprosto nic se na jeho pouzivani nezmeni, nejake ODF stejne jako doposud se nijak neprosadi. Ale k jednomu prece jenom muze dojit a to je velmi zasadni! A sice, ze MS bude moct kdykoliv OOXML zmenit, ale kdyz to bude norma, tak NE! Z tohoto duvodu jsem osobne byl vzdy pro prijeti ISA pro OOXML, je spravne, ze se to pripominkovalo, ze kolem toho byl nejaky humbuk, ale ten humbuk je az prilis zprofanovany a to uz mi tak spravne neprijde. Jeste jsem zapomel na vasi posledni odrazku a to je ten VB. Osobne VB moc rad nemam (jsem spis ceckar), ale je to u MS klicova technologie, je zdokumentovany, pouziva se v MSO uz dlouhe roky, tak MS urcite nema duvod ho menit, zvlast kdyz vsichni vyvojari dokumentu pro MSO a vlastne i vsechny dokumenty pouzivaji VB, tak by bylo nesmyslne a vlastne i nemozne ho tam nedat kvuli zpetne kompatibile.
Jeste o tom nahrazovani, vlastne o nahrazovani nejde, ODF tu prakticky nikdy nebyl a uz evidentne ani nebude. OOXML ma kazdopadne sirsi moznost uplatneni, srisi funkcionalitu, navic je podporovan nejvetsim a nejrozsirenejsim kancelarskym balikem a kdyz ISO donuti MS drzet se toho standardu, tak ja rikam BUDIZ OOXML ISO! -
Pokud je to formát jen a pouze pro MSO, tak nemá cenu ho standardizovat. Standard je něco, co může vzít kdokoliv (za určitou licenční sumu) a plně to implementovat. ODF tu není jen pro OO.o, je tu pro výměnu dokumentů bez problémů s kompatibilitou mezi různými kancelářskými balíky. Není důležité, že do ODF nejde uložit nějaký potrhlý grafický efekt zatímco do OOXML jde, ale že ODF v tuto chvíli funguje naprosto stejně ve víc než tuctu různých kancelářských balíků včetně MSO (se Sun ODF pluginem), zatímco vyhlídky na brzkou plnou implementaci OOXML zcela nezávislou na Microsoftu jsou velmi malé (z technických důvodů).
Podle jmen tagů bych si navíc dovolil hádat, že specifikaci OOXML nepsal člověk, ale Microsoft ji vygeneroval přímo z komentářů a zdrojových kódů načítacích rutin v MSO. -
Uživatelka si přála zůstat v limbu (neregistrovaný)No jo, ale ten proces by taky měl respektovat nějaká pravidla, ne?
A co se týče těch různě se jmenujících tagů, tak to imho je jenom kosmetický problém. Přece jenom, normálním lidem to bude parsovat počítač, kterému by nevadilo ani kdyby to byly arbitrární hexadecimální čísla, že jo. A blázni by měli být rádi, že to teď budou mít s ruční tvorbou dokumentů náročnější, vždyť se v tom přece vyžívají, ne? -
anonymníMyslím, že Češi z formálních důvodů s klidným svědomím...
Lez hned v uvodu vety:o) Nicmene, ja spolu se zastupem lidi s IQ vyssim nez 50, budem nadale verit panu Koskovi, ktery je zjevne fundovanou a nanejvys odbornou osobou na dane tema (navic narozdil od ostanich vcetne vas nebo me, kdo kdy zadali do prohlizece www.root.cz, on ISO dokument zjevne cetl), nez vam, kteryzto, a ruku na srdce, jste uplna nula (a to minimalne v oboru OOXML).... -
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? -
anonymníNení mi jasné, proč se výsledný hlas týká pouze toho, zda byly vyřešeny české připomínky. Ano, nejspíš byly vyřešeny. Ale přece nebude každý stát dávat svoje připomínky zcela duplicitně s ostatními státy? Copak není možné se ztotožnit s nedořešenými připomínkami např. švédkými, francouzskými atd, a ty prohlásit za důvod pro hlasování "Ne, s výhradami". Výhrady by byly totožné s těmi od jiného státu. Pokud by byly uspokojivě vyřešeny i všechny připomínky jiných států, bylo by to v pořádku. Ale přece nikoho nemohlo napadnout, že pro korektní průběh připomínkování je třeba, aby každý stát vznesl i připomínky jiných států (odhadem by tedy bylo 40*900 = 36000 připomínek)!
-
Určitě jsem oproti vám všem 100 let za opicema a nejsem vůbec hoden jakoliv se k OO XML vyjadřovat, ale jen tak sem se podíval na nějaký připomínky a tohle mě zaujalo:
Comment: Je zcela nepřijatelné vkládat fragment XML do atributu.
Proposed change: Místo atributu gfxdata použijte podelement, který umožní přímé vložení fragmentu XML.
To jsou hacky :). -
jenda (neregistrovaný)musim priznat, ze ja stojim na strane mych zakazniku. A ti chteji faxovat nejake .doc dokumenty, ulozena na nejakem serveru. Jestli je nejaky pan Kosek podplaceny nebo ne je jim u prdele.
Nemohl by mi nekdo tedy sdelit, jak se jmenuje ta knihovna (za penize nebo free), kterou si prilinkuji k me C aplikaci a pomoci teto pretransformuji ten .doc soubor do g3 nebo tiffg3 souboru?
