To, že každý, bez ohledu na platformu, OS či kancelářský balík má právo číst dokumenty, je velký nesmysl. Takové právo neexistovalo, neexistuje, a zřejmě nikdy existovat nebude.
Formát ODF vznikl právě proto, aby takovou věc umožnil. Proto se na něm všichni rozumní výrobci kancelářských balíků shodli a postupně ho implementují. Takže zřejmě existovat bude.
Jako zastánce tržní ekonomiky jistě víte, že spojení konkurentů proti monopolu je v tržním prostředí obranou zcela typickou - takže nechápu, na co si stěžujete.
Konkurenční firmy neprotestovaly proti snaze prosadit OOXML jako standard ale proti typickým praktikám Microsoftu, za které by se nemusela stydět ani Ukrajinská mafie.
Velmi se těším na dobu, až si budu moci vybrat takový kancelářský balík, který mě vyhovuje a plní mé potřeby bez zdržujících a zbytečných sračiček okolo a bez ohledu na to, co náhodou požívá můj šéf nebo nějaký mnistr. Věřím, že se dočkám.
Mám v úctě solidní podnikatele. pro které jsem zákazník a nikoliv rukojmí. Svině jsem nikdy nepodporoval a nehodlám je podporovat ani v této branži. Myslete si o mně, že jsem fanatik - chcete-li.
Nakonec ono je jedno, jestli je ve specifikaci fo:color, nebo pár náhodně zvolených znaků.
To je Váš názor. Nicméně XML původně vzniklo s ohledem na čtení a psaní pokud ne uživatelem, tak alespoň programátorem. Nepředpokládalo se, že to bude formát, se kterým nebude možné manipulovat bez masivních nástrojů.
MS se nám snaží namluvit, že jedno- ař tříznakové tagy míchající malá a velká písmena (což jsou v oblasti XML zavrhované praktiky) jsou "nezbytné z hlediska výkonu". Já jsem však nepřišel na žádný důvod, proč by streaming parser měl být prodloužením délky tagů ovlivněn. Nejen z hlediska asymptotické složitosti - mnohem více výpočetního výkonu spotřebuje sledování struktury a vytváření vnitřního stromu objektů a velikost komprimovaného souboru také je jen stěží ovlivněna.
Nicméně MS přesto bez předložení jakýchkoli ověřitelných argumentů navrhl snad jedinou XML aplikaci, jejíž znařky nemají deskriptivní názvy (nebo jedinou novou aplikaci, XHTML přebralo značky z HTML, a XML TEI zase převzalo značky z SGML TEI).
Ohledně výkonu jsem neprováděl žádné testy, ale vezměte v úvahu, že dokument Office není jen jednostránkový dopis babičce, ale také 300-stránková smlouva, kterou chcete ukládat na pozadí.K tomu jsem se už vyjádřil, neumíte číst? Nevěřím tomu, že by se jednalo o natolik výrazný pokles výkonu, a programátoři odjakživa ctí pravidlo "nejdřív profiluj a až pak dělej dalekosáhlé závěry". "Bylo by to pomalé, radši porušíme základní návrhová pravidla XML aplikací" je dalekosáhlý závěr, který jsem ještě neviděl nijak podložený.
Zrovna v případě XHTML mi namátkou tagy bdo, g, tfoot, th, tr, tt a xmp nepřipadnou zvláště deskriptivní. Vám ano?
Opět nečtete. Jasně jsem zdůraznil, že mluvím o nově navržených XML schématech. HTML je (při vší úctě k jeho tvůrcům) archaický bastl, a XHTML 1.0 je pouze "a reformulation of HTML 4 as an XML 1.0 application" (cituji přímo z abstraktu W3C specifikace). Chuck Moore, autor jazyka Forth, ve kterém je kladen důraz na kompaktnost, opakovaně prohlašuje, že umění volit správné názvy "slov" (v jazyku Forth se tak říká funkcím) je klíčová schopnost programátora. U XML schémat tomu nebude jinak, je třeba volit názvy, které nebudou příliš dlouhé, ať by přitom byly sebesrozumitelnější, ale zase je zcela nepřístojné vydávat "w:pPr" za přijatelné názvy značek. Je mi líto, panu Bechyňskému se mě a mé kolegy na XML konferenci opravdu v tomto směru nepodařilo přesvědčit.
V případě XML je stejně skoro nezbytné rezignovat na hrubý výkon. Vybavuje se mi Ogbujiho citát "I think Linus Torvalds himself would take years to write a complete and correct XML parser. It's the nature of the beast (XML), not the programmer." Nabízí se otázka, jestli místo pokusu o urychlení parsování zkrácením tagů o pár písmenek není lepší použít méně záludný formát. Osobně bych místo XML v případě takové přehnané starosti o výkon při zachování požadavku na textovou reprezentaci navrhoval používat S-výrazy. Třeba tohle:
<w:p><w:pPr><w:pStyle w:val="Heading1"/></w:pPr><w:r><w:t>Example document</w:t></w:r></w:p>se dá izomorfně napsat třeba takhle (S-XML by ještě navíc převedlo atributy do podelementů s názvem "@" a zrušilo by tak tenhle schizofrenní rys XML, ale to tu pomíjím):
(w:p (w:pPr (w:pStyle :w:val "Heading1")) (w:r (w:t "Example document")))Navíc parser pro S-expy je jednodušší (a líp se vejde do cache), rychlejší - nejen kvůli tomu, že polovina zobáčků ubyde, ale i proto, že v nich není spousta XML zrůdností, se kterými conforming XML parser musí počítat. Blíž se k efektivitě binárního dokumentu pro hierarchické struktury (pominu, že S-výrazy umějí i DAGy a cyklické orientované grafy ;-)) člověk asi nedostane. :-) To já jen k tomu, že pokud chcete ždímat rychlost, jsou i efektivnější cesty, dokonce i pokud nechce jít do binárního formátu (což nese komplikace s indiány), a není třeba si hrát na M$-pokrytce.
komu a proč by MS měl předkládat ověřitelné argumenty ohledně rychlosti parsování, když se jedná o jeho vlastní formátNejspíš konzorciu OASIS? :-) (Pokud je neznáte, seznamte se.) Tedy pokud by chtěl zdůvodnit, proč ten formát vypadá tak, jak vypadá - nejde o rychlost, jde o zdůvodnění porušených zásad. To bylo míněno zcela vážně, protože pokud si firma XYZ chce nechat svůj formát standardizovat, tak to tak nějak přestává být "jen její vlastní formát" - doufám, že tento drobný detail není pod Vaší rozlišovací schopností. :-)