Jak vite, ze neni mozne ho implementovat? A musi byt pro standardizaci mozne standard 100% implementovat kdekoliv, nebo pouze nekde, kde, nebo musi existovat v dobe schvaleni 100% implementace??Neni mozne, protoze Microsoft neudelil vseobecnou royalty-free licenci k 'Intellectual Property' (rozumej: napr. k detailum chovani produktu, na nez ma OpenXML specifikace odkazy, k Windows Metafile, ...). Prohlaseni o Intellectual Property Rights je chytre maskovane konstatovani, ze implementatorum Microsoft nic nedava. A protoze zaroven M$ neucinil prohlaseni ze je _cela_ specifikace a vsechny nutne metody, postupy, algoritmy a chovani patent-free, tak nejmene implementatori v U.S. budou mit velky problem.
> Pokud je neco ISO standard, pak je jeho obsah od patentu oprosten.
To určitě ne, viz např. MPEG‑2 (ISO/IEC 13818) nebo MPEG‑4 (ISO/IEC 14496), které obsahují mnoho patentovaných technologií (MPEG‑2, MPEG‑4), a za které jsou požadovány licenční poplatky. Pokud vím, tak ISO pouze vyžaduje, aby licenční podmínky byly „rozumné“ a nediskriminační, označuje se to jako RAND — Reasonable and Non Discriminatory Licensing.
Ale situace je proste takova, ze tu nemame nejake vzduchoprazdno a nevybirame si, co by v nasledujicich deseti letech byl asi tak dobry office format. V soucasnosti ma microsoft naprostou prevahu v office, jeho formaty (at jsou jakekoliv a zejmena binarni a uzavrene) jsou de-facto standardem (krome malych technickych akademickych ostruvku a skupin nadsencu). V serioznim obchodovani s partnery se bez nich temer neobejdete.
OpenXML nyni ted hned okamzite v podobe Office 2007 ma kompletni a uplnou implementaci. ODF chybi nektere dulezite funkce a kompletni jeho implementace neexistuje. To, ze se nektere casti mohou pozdeji do ODF doplnit, neresi problem, ze je potrebujeme ted. Sproste receno, neuplny ISO standard je horsi nez uplny ne ISO standard. Firmy a zakaznici nebudou cekat, az se nejake komise dohodnou a pak to nekdo nejak naprogramuje. Oni pouzivaji office dokumenty kazdy den. Zivi se tim.
To je ta stara filosoficka otazka, jestli byla drive implementace nebo finalni verejna specifikace. Viz priklad HTML3.0 a nejnoveji i XHTML2.
A co rikate na OpenDocument criticism?
Cili navrhujete aby microsoft pouzival ODF a doplnil ho vlastnimi tagy?Chlapce, chlapce, slysel jste nekdy o XML namespaces ? Spravne by mel M$hit to co LZE namapovat do ODF zapsat do dokumentu podle ISO normy (= ODF), a na veci "navic", ktere v produktu ma a kterymi se chce diferencovat od ostatnich vyrobcu (napriklad ty "format-like-ms-word") zapsat jako sve vlastni tagy, ve vlastnim namespace. Jednou z vyhod XML je pomerne slusna rozsiritelnost. Jestli svuj namespace pak zdokumentuje nebo ne... a jak dobre, to uz je problem M$ a tech blahovcu, kteri se snazi s M$ neco integrovat a jeste se nepoucili z neustalych nekompatibilit v dalsim release.
Aktualni pozadavek verejne spravy je otevreny format. Ne konkretne ODF.Nevim proc by to mel delat, ale pozadavek na otevreny format pro mnohe implikuje inter-operabilitu mezi programy. Jiste ne pro Vas a urcite ne pro M$, ktery poddokumentovanym, slozitym, zavislym na vecech vyzadujici extra licence (WMF, 'doLikeWord95') atd zachovava vendor lock-in. Implementovat nezavisle cteni/zapis do OpenXML je jiste mozne, ale zrejme to neni vubec jednoduche, a o to prave jde :) Vlk (pozadavek na 'otevreny format') se nazere a koza diky vysoke bariere a nakladum na prechod nebo i integraci budou zakaznici opet volit produkty Jedine Softwarove Firmy. Proc se OpenXML brani ostatni (kteri mezitim prijali existujici ODF) je logicke: pro ne je 'ja vim vsechno nejlip' jenom naklad navic - protoze ve vysledku museji doprogramovat alespon zdani podpory OpenXML i do svych produktu...
Mozno je nacase, aby ISO zmenilo tento pristup. Vyskum a moznosti IT idu neskutocne rychlo. Dosledkom tohto je aj vyvoj v riadeni projektov, ked stare a komplexne metodiky vyvoja s oddelenymi fazami vyvoja stupuju agilnym metodikam vyvoja
ODF ide podla mna spravnou cestou, radsej jednoduchsi format, ktory nema uplne vsetky vychytavky, ale je mozne ho rozsirovat a uspesne rozsirenia neskor standardizovat. SW bude vzdy o krok pozadu za standardom, ale presne a jasne specifikovanu podmnozinu formatu (== aktualny standard ) budu implementovat rovnako.
Na druhej strane, 6-tisic stran OOXML, ktore sa snazi dnes mysliet na spatnu kompatibilitu, ktoru vsak ani autor OOXML nedokaze popisat platformovo nezavislym jazykom, cim vlastne znemoznuje implementaciu daneho standardu, je pre kazdeho vyvojara najhorsia nocna mora, pretoze to nikto nedokaze implementovat. Po case to neimplementuje spravne ani samotny autor specifikacie, pretoze nebude vediet co je vlastne podla specifikacie spravne.