Jiří Kosek: XML už je všude
Zeptali jsme se Jiřího Koska, jak probíhal proces připomínkování OOXML za Českou republiku, proč na CSS3 čekáme již 10 let, jaké problémy vidí na XHTML a také jak hledí na budoucnost XML a na jeho konkurenční formáty. Jiří Kosek nám také přiznal, že dokončuje svou další knížku.
Nálepky:
Dnes přinášíme druhou část rozhovoru s Jiřím Koskem. V první části rozhovoru jsme se věnovali W3C. Dnešní část bude trochu pestřejší. Zaměříme se nejen na práci W3C, ale i na standardizační organizace ISO a OASIS. A také na budoucnost některých webových technologií.
Nedávno jsi měl poměrně důležitý úkol při schvalovacím procesu, který se týkal OpenXML. Co přesně jsi dělal?
Jelikož jsem byl zpracovatel mezinárodní spolupráce výboru ISO/IEC JTC1/SC34, bylo mým úkolem přečíst návrh této normy, která měla přes 6 tisíc stránek. Navíc jsem jako mezinárodní zpracovatel byl zodpovědný posbírat připomínky od všech zainteresovaných subjektů.
Do té doby to byl jednoduchý úkol, protože normy, které tento podvýbor schvaloval, nikoho příliš nezajímaly. Četl jsem je já sám a posílal jsem připomínky, které byly víceméně moje, byť byly za celou ČR. Jelikož OOXML bylo žhavé téma, přiměl jsem ČNI, aby zřídili na svém webu prostor, kam může připomínky poslat kdokoliv.
A to není obvyklé?
Ne, v ČNI to nebylo obvyklé. ISO vznikalo v podobné době jako OSN a z dnešního pohledu tak má svá vnitřní pravidla poměrně zvláštní. No a národní standardizační organizace (u nás ČNI, nyní přejmenované na UNMZ) jsou tímto duchem také ovlivněny.
Na jednu stranu od zpracovatele vyžadují, aby zajistil prodiskutování návrhů normy mezi všemi subjekty, které téma zajímá. Na druhou stranu kvůli copyrightu ony návrhy norem nesmějí dát nikomu, kdo není členem jejich technické normalizační komise. Je to celé trochu zamotané.
Naštěstí podvýbor SC34, kde pracuji, funguje dobře a všechny dokumenty jsou veřejně přístupné. Nebo dlouhou dobu byly, minimálně návrhy norem.
XML už je prostě všude.
Takže jsem shromáždil připomínky. Navíc jsem měl nějaké vlastní, jelikož jsem celý text přečetl.
Některé připomínky byly relevantní více, jiné méně. Vybral jsem, které by se měly stát součástí stanoviska za ČR. Následně dostali šanci ti, jejichž připomínky byly zamítnuty. Mohli zdůvodnit, proč by přece jen měly být zahrnuty. Následovalo osobní setkání, kde se diskutovaly zbylé sporné připomínky. Nakonec vznikl seznam připomínek za ČR, který byl do ISO odeslán společně s návrhem hlasu.
Pokud vím, připomínek nebylo právě málo.
Ano, řada lidí OOXML kritizovala a celkem oprávněně. V návrhu normy OOXML byla řada problémů, to samozřejmě ano. Připomínek bylo velké množství, ale poměrně rychle se objevily návrhy, jak řadu z nich vyřešit.
Ovšem ISO se rozhodlo, že návrhy řešení připomínek nezveřejní. Argumentovali tím, že komentáře jednotlivých států jsou chráněny copyrightem těchto států, ISO nemá souhlas tyto připomínky zveřejnit, proto nemůžou zveřejnit ani návrhy, jak se s připomínkami vypořádat, protože tím by museli zveřejnit i ony připomínky a porušili by copyright. Těžko říct, nakolik to mysleli vážně, a nakolik to byla zástěrka.
Já jsem jim psal, že připomínky ČR jsou zveřejněné, ať aspoň zveřejní reakce na připomínky ČR. Dostal jsem i souhlas od editora, který za ECMA vypracovával návrhy na vypořádání připomínek. Urgoval jsem to dvakrát, ale ze sekretariátu ISO se mi vůbec neozvali.
OOXML spadlo mnoha lidem v SC34 do klína poněkud nešťastně. ECMA zaslala specifikaci do ISO a tam vybrali pracovní výbor, který se zabýval XML, podle logiky, že OOXML je postavené na XML. Většinu lidí tím zrovna nenadchli.
Mohl jsem teoreticky ČNI říct, že na tak rozsáhlý úkol nemám čas a odmítnout to, ať si s OOXML dělají, co chtějí. Pravděpodobně by pak udělali to, co do té doby dělali i u některých dalších norem. Nejspíš by řekli: „Nebudeme se o to zajímat a pošleme ano“. To mi přišlo škoda, protože OOXML je formát, který bude používat řada lidí, tak proč nevyužít možnost opravit problémy.
Tvou hlavní doménou je XML. Před lety se říkalo, že budoucnost je v XML, které mělo nahradit prakticky všechny další formáty. Vzpomínám, když ty jsi v české skupině uživatelů LaTeXu vysvětloval, že budoucnost je v DocBooku. Dnes mám pocit, že pomalu nastává trend opačný a jistý odklon – objevuje se zklamání z XML a začínají se prosazovat dílčí specifické formáty. Jak to vidíš ty?
Já bych to necharakterizoval jako návrat někam jinam ani jako odklon. Já si totiž myslím, že XML už je prostě všude, jen se o tom už nemluví, proto není tolik viditelné. Ale kam se člověk podívá, tam je XML.
Čím dál víc lidí dokumenty primárně pořizuje v XML, ať už je to DocBook nebo jiný formát. TeX je výborný sázecí engine, ale čím dál míň lidí používá TeX (LaTeX, ConTeXt nebo jiné nadstavby) jako primární formát pro pořizování dat. Je nešikovný a s daty pak nejde dělat skoro nic jiného, než je nechat TeXem naformátovat.
Znám spoustu lidí, kteří dříve používali TeX. Oni jej používají pořád, ale již ne jako primární zdroj dat. Data dnes mají v XML, z něj transformací vygenerují třeba TeXový zdroják a z něj generují PDF.
Ale na webu se prosadil JSON. A to na mnoha místech, kde vévodilo XML.
Já bych s JSON počkal pár let, jak se to vyvine. JSON byl populární v tom, jak byl jednoduchý. Syntakticky je to podmnožina JavaScriptu. Když chcete v AJAXové aplikaci data ze serveru, stačí poslat XMLHttpRequest, na výsledku zavolat funkci eval a je hotovo – v paměti je objekt s daty.
Na malé pokusy a hraní to bylo úžasné. Ale jakmile začnete JSON používat v masovém měřítku, musí se řešit problémy, např. že eval není bezpečný a měl by se tam vložit parser. Pak se zjistí, že by bylo dobré data validovat, tak se přidá schéma. Takže se udělá úplně to stejné, co už v XML je.
Já osobně tohle vidím jako jistý odklon od XML. Vybere se jen to, co je na XML dobré, ale protože lidem něco na XML vadí, tak hledají jinou cestu.
Oni budou hledat jinou cestu, ale budou opakovat chyby, které se dělaly při vývoji XML. Protože u XML se stejně opakovala cesta z vývoje SGML nebo jiných jazyků. Historie se pohybuje v kruzích. Někteří lidé mají z nějakého důvodu alergii na špičaté závorky, tak se v JSON používají složené závorky. Já si myslím, že pro větší kusy dat je to ještě méně přehledné než XML, ale to je věc názoru. Řada lidí si myslí, že nejlepší by bylo psát v LISPové syntaxi, tedy v kulatých závorkách, ale to už tu taky bylo.
A proč lidi začali JSON používat? Protože v JavaScriptu jsou nemožná API pro práci s XML. Webové prohlížeče používají DOM, což je z existujících XML rozhraní skutečně to nejhorší. Minimálně co se týče praktické použitelnosti. Kdyby v JavaScriptu šlo přijmout data v XML a rovnou z nich udělat v paměti objekty, tak se JSON možná neprosadil. Objevily se již návrhy na zlepšení např. E4X, které implementuje Mozilla.
Já se JavaScriptu snažím vyhýbat. A myslím, že by měly vzniknout nadace a sanatoria pro vývojáře webových aplikací, kteří musí psát interaktivní aplikace v JavaScriptu. (smích) Dnes je to ovšem už lepší, prohlížeče jsou kompatibilnější a všichni používají knihovny, které je od rozdílů odstíní.
Web je v tomhle specifický. XHTML má své problémy, takže to pověst XML na webu trochu pošramotilo. Ale v mnoha jiných oblastech se již XML pevně usídlilo.
Proprietární technologie jako XAML v Silverlightu ukazují, že trh si řešení, která vedou k rychlejší a bezpečnější tvorbě aplikací, žádá.
Co konkrétně se podle tebe nepovedlo na XHTML 1.0? A co na XHTML 2.0? V čem se mělo postupovat jinak?
Začněme u XHTML 1.0. Největší problém byl v tom, že ten jazyk nenabídl nic nového, co by uživatele motivovalo opustit HTML – možnosti zůstaly stejné jako u HTML 4.01, jen se zpřísnila syntaxe, což byla pro mnoho autorů spíše komplikace. Na technické úrovni byly v XHTML 1.0 také chyby – například tím, že se vyžadovala přítomnost !DOCTYPE a specifikace byla nešikovně napsána, nebylo možné držet se striktně XHTML 1.0 a přitom využívat výhody XML, jako možnost mixovat SVG, MathML nebo vlastní sady značek v dokumentu XHTML.
Problém byl i na straně tvůrců prohlížečů. Microsoft dosud XHTML podporuje jen v rovině rétoriky. Nevím jak dnes, ale v začátcích Mozilla neuměla XHTML vykreslovat postupně během načítání zdrojového kódu stránky – čekala, až se načte celý dokument, z něj se vyrobil DOM a až ten se předal vykreslovacímu jádru. Pro větší stránky přenášené přes pomalejší připojení to byla z hlediska uživatelského požitku degradace oproti HTML, které se vykreslovalo progresivně.
Vývoj CSS3 trvá tak dlouho, protože CSS3 nikdo nepotřebuje.
A XHTML 2.0?
XHTML 2.0 se hodnotí těžko, protože mnoho klíčových věcí se v návrhu specifikace pořád ještě mění. První návrhy XHTML 2.0 zcela odřízly zpětnou kompatibilitu s XHTML – používal se jiný jmenný prostor než pro XHTML 1.0. Pro prohlížeče tak dokumenty XHTML 2.0 byly zcela neznámé dokumenty obsahující zcela neznámé elementy.
Na tak radikální změnu nebyli připraveni autoři stránek a hlavně výrobci prohlížečů. Snad žádný výrobce prohlížeče neohlásil záměr XHTML 2.0 v této podobě implementovat. A možnosti CSS jsou pořád nedostačující na to, aby se zobrazení a chování XHTML 2.0 dokumentů popsalo pouze pomocí něj a nebyla nutná speciální podpora v prohlížeči.
V poslední době se autoři XHTML 2.0 rozhodli radikálnost návrhu trochu omezit, například se vrátili zpět k původnímu jmennému prostoru XHTML. Jenže v té době již ve W3C pracovala nová pracovní skupina HTML vytvářející HTML5. HTML5 však kromě HTML syntaxe definuje i způsob serializace do XML – je to v podstatě XHTML (někdy se označuje jako XHTML5), ale elementy a atributy jsou stejné jako v HTML5. Takže v současné době W3C pracuje na dvou „nástupcích“ XHTML 1.0, tj. na XHTML 2.0 a na XML serializaci HTML5 (XHTML5), kteří nejsou vzájemně kompatibilní. To je ožehavý problém, který bude potřeba na půdě W3C nějak vyřešit.
Samozřejmě z principiálního hlediska je myšlenka psaní webových aplikací více deklarativním způsobem pomocí XHTML+XForms+XBL+SVG+SMIL zcela správná. Je to rozhodně lepší než tuny javascriptového kódu a frameworků, které se dnes s každou stránkou načítají a provádějí. Konec konců proprietární technologie jako XAML v Silverlightu ukazují, že trh si řešení, která vedou k rychlejší a bezpečnější tvorbě aplikací, žádá.
Uvidíme, zda si v budoucnu XHTML svou pošramocenou pověst vylepší. Obávám se, že to bude chvíli trvat, naději však dává mobilní web, kde se XHTML zcela běžně používá.
Jinak častému argumentu proti XHTML – příliš striktní syntaxi nevěřím. Jednak opravdu není problém dokumenty psát tak, aby syntaxi neporušovaly, zvláště pokud člověk používá vhodné nástroje pro editaci kódu. Navíc při vhodném výkladu specifikací prohlížečům nic nebrání v tom, aby se z chyb v XML zotavily a něco zobrazily.
Řekněme, že mám geniální nápad a chtěl bych z něj vytvořit specifikaci u W3C. Mohl bych jen tak přijít, W3C by pro mě založilo pracovní skupinu a já bych s pár kamarády začal specifikaci vytvářet? Nebo je to složitější?
S pár kamarády ve W3C těžko, protože o tom, kdy vznikne pracovní skupina, rozhodují platící členové. Když několik členů chce na něčem pracovat, řeknou, že by chtěli založit pracovní skupinu. Následně W3C schvaluje, zda cíl skupiny zapadá do jejího kontextu a pokud někdo není zásadně proti, skupina vznikne.
Pokud bys skupinu chtěl jako jednotlivec, musel bys přesvědčit několik platících členů, aby takový návrh podali a z tebe udělali invited experta.
Z toho je vidět, že platící členové mají zásadní slovo a vliv na budoucnost celého W3C.
Jistě, W3C je přece jejich konzorcium. Plus z historických důvodů má silné slovo ředitel W3C Tim Berners-Lee, ale jinak je to sdružení členů.
Tímto způsobem v zásadě funguje většina standardizačních organizací, např. OASIS a ECMA. Jediný, kdo funguje jinak, je ISO. V něm jsou členy jednotlivé státy, resp. jejich národní standardizační instituce.
Kdybys měl srovnat W3C, OASIS a ISO. Která organizace ti připadá nejlepší a proč? Která má procesy postaveny nejlépe?
Těžko soudit, jestli nejlépe. Záleží, co člověk sleduje. Kupříkladu W3C dokáže být ze všech nejagilnější. Jsou schopni nejrychleji specifikaci vyvinout a dotáhnout do konce.
To ale zní docela paradoxně, když se podíváme, jak dlouho trvá vývoj CSS3.
Vývoj CSS3 trvá tak dlouho, protože CSS3 nikdo nepotřebuje. Tam není poptávka.
Ale přece webdesigneři si už téměř 10 let stěžují, že tu CSS3 dávno mělo být.
Jenže webdesigneři píší kód pro prohlížeče. Museli by vytvořit nějaký tlak na vývojáře prohlížečů. Ale webdesigneři nejsou skupina, která vytváří tlak na vývojáře prohlížečů, ten vytváří uživatelé. A uživatelům je jedno, jakou verzi kaskádových stylů prohlížeč podporuje.
Ono uživatelům by bylo jedno, kdyby se dodnes používal tabulkový layout. Chtějí si prohlížet stránky, nakupovat, bavit se. Je jim jedno, zda je stránka udělaná v tabulkovém layoutu, v kaskádových stylech nebo ve Flashi. Hlavně potřebují, aby to fungovalo. A web tak nějak funguje.
Že by to šlo technologicky udělat lépe, že CSS3 obsahují super možnosti pro tvorbu layoutu a weby by se designerům dělaly líp, šlo by snáze vytvořit web, který bude dobře vypadat na malém monitoru i na velkém, to je všechno pravda, ale samo o sobě to nestačí.
Proč je tedy W3C agilní?
W3C je agilní, protože nejčastěji pořádají telekonference a osobní setkání. To samozřejmě vyžaduje poměrně hodně času a je to i finančně náročné, čili těžké pro jednotlivce (invited experta) se účastnit. Nyní, když na firmy dopadá ekonomická krize, jedná se o problém i pro členy z velkých firem. Škrtají se rozpočty a první, co se škrtá, je cestování na standardizační meetingy, protože z toho firma nemá okamžitý příjem.
A další organizace? Jak je na tom OASIS?
OASIS osobní setkání téměř nemá. Většinu věcí řeší e-maily a na telekonferencích. To je dobré, jednání se může účastnit mnohem víc lidí, protože tam nejsou finanční náklady na cestování. Na druhou stranu to jde celé pomaleji.
Když jsme se bavili o OOXML – jeho protipólem je podobný standard ODF vyvíjený v OASIS, jehož vývoj se vleče. Hodinová telekonference jednou týdně zkrátka nikdy nenahradí týdenní osobní setkání, kde se nedělá nic jiného, než že se řeší problémy – tam jde vše samozřejmě mnohem rychleji.
A ISO?
ISO, to je takový kostlivec. U něj hodně záleží na pracovní skupině. Například SC34 bylo opakovaně útočištěm pro technologie, které v nějakou chvíli nebyly mainstreamové, ale prostě určitá část expertů si myslela, že je to lepší, než co dělá W3C.
Takže zatímco W3C mělo XML schémata, která spoustu věcí neřeší ideálně, v ISO se standardizoval RELAX NG nebo třeba Schematron, který některé věci doplňuje. Pokud se podíváte na XML schémata ve verzi 1.1, přijímají ze Schematronu i RELAX NG to, co se ukázalo jako nejvíce potřebné, takže se to ovlivňuje i zpětně.
Můžu reklamu? Na konferenci XML Prague v březnu tady v Praze bude Michael Kay mít přednášku o nových funkcích schémat 1.1. Koho to zajímá, může se zúčastnit.
(Pozn. redakce: Zdroják je mediálním partnerem konference XML Prague.)
Jiří Kosek navrhl „XML dort“, který dostal Norman Walsh ke svým 40. narozeninám.
V SC34 se vyvíjejí i Topic Maps, které lze z jistého úhlu pohledu použít na podobné věci, jako sémantický web od W3C. Ale nejsou tolik abstraktní a na tak nízké úrovni, takže se v nich lépe modeluje řada druhů aplikací.
Pokud někoho zajímají věci, které dělá SC34, a chtěl by se na nich podílet, vylepšovat standardy nebo dělat prototypové implementace, nechť se mi ozve. Rád se s ním o tu nevděčnou práci podělím, budu mu přeposílat pracovní návrhy, aby za Českou republiku vzniklo víc a lepších připomínek.
Stejně tak, pokud někdo najde chybu v ISO verzi OOXML nebo ODF. Ať mi ji pošle, já ji postoupím na odpovídající místa.
Než se s tebou rozloučím, mám poslední otázku. Slyšel jsem, že píšeš další knížku. Povíš nám, o čem bude?
Je to pravda. Jedná se o knihu o práci s XML v PHP. Už mi chybí napsat jen předmluvu a závěr.
Takže vyjde ještě letos?
Raději nebudu dělat žádné sliby, ale pokud všechno půjde dobře, doufám, že by mohla vyjít letos.
Byl to takový můj rest. Do mojí, dnes už prehistorické, knihy o PHP3, se o XML nic nevešlo. To mi bylo líto. Na druhou stranu je to možná dobře, protože ve verzi 3 byla podpora XML skoro nulová.
(Pozn. redakce: Minulý týden byl plný text dnes již historické knihy PHP – tvorba interaktivních internetových aplikací zveřejněn a nabídnut volně ke stažení.)
V PHP verze 4 byla podpora XML všelijaká. Ve verzi 5 už je rozumě použitelná. Byť PHP má řadu problémů, do teď pořádně nepodporuje Unicode, což při práci s XML je nutné různě obcházet, ale už v něm z XML rozhraní najdeme vše, co je potřeba.
V téhle knížce budou popsaná všechna XML rozhraní v PHP5 a jak je používat. A také tam budou popsány základní XML technologie, např. syntaxe, schémata a transformace. Lidem, kteří potřebují s XML pracovat v PHP, by měla stačit. Je nakonec dobře, že se XML do knížky o PHP3 nevešlo, protože svými rozměry se jí tahle kniha skoro blíží.
Držím palce, ať se i další tvé knize daří a děkuji za rozhovor.
Otázky za Zdroják kladl Martin Hassman, fotografie pořídila Ivana Dvorská a Jiří Kosek.
Sledujte rubriku rozhovory
V rubrice rozhovory na Zdrojáku najdete i další zajímavé rozhovory s osobnostmi z oboru:
- Václav Stoupa: akce typu WebExpo se u nás nekonaly
- Karel Břinda: I mezi nevidomými uživateli jsou programátoři
- Jan Odvárko: na Firebugu je radost pracovat
Martin Hassman
Martin Hassman založil a vede magazín Zdroják. Absolvoval VŠCHT Praha. Byl u založení projektu CZilla (dnes už nepamatujete, nevadí). Stavěl mosty a metal cestu pro HTML5 (to tu ještě máme). V GUG.cz organizoval akce pro vývojáře (a jestli neumřeli, kódují si dodnes…).
JSON je hlavne format, ktory je urceny na serializaciu na rozdiel od XML, ktory bol vytvoreny hlavne pre podporu strukturovanych dokumentov.
Osobne si myslim, ze s pouzitim XML sa to dost prehana..
A to jeste slusne receno.
Opravdu? Z toho popisu formátu mi to tak nepřišlo. Jak řeší dvě ze základních situací serializace, sdílené a cyklické odkazy?
Definicia priamo z http://www.json.org/
JSON (JavaScript Object Notation) is a lightweight data-interchange format..
JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
mne sa data-interchange spaja so serializaciou
Pokial viem tak neriesi.. asi preto, ze je "lightweight", na to by sa mozno hodil YAML (nadmnozina JSON-u), ten by to mal riesit, ak si dobre spominam..
Jo jo. Vsechno je dnes v XML, prestoze vysledkem je kod 2x tak dlouhy a 3 x tak siroky. Mnohem mene prehledny atd.
XML je dobry pomocnik a radce ovsem spatny pan.
Pokud vím, tak XHTML jakožto XML strukturu není možné podle pravidel W3C zpracovávat průběžně, musí se počkat, až je dokument natažený v paměti celý, pak se musí provést kontrola validity, a teprve pokud nejsou nalezeny chyby, na kterých prohlížeč musí selhat, může být provedeno zobrazení dokumentu.
Neúplně stažený XML soubor nemůže být validní, minimálně protože nemá uzavřený kořenový tag.
Co se validity týče máte pravdu. Ta se težko ověřuje před tím, než se stáhne celý dokument. To se ovšem netýká renderování. Tam si může klidně prohlížeč uzavírací tagy více či méně inteligentně doplnit a poté částečný dokument zobrazit.
K tomu by som mal jednu poznámku. Špecifikácia HTML priamo predurčuje, ako sa má nakladať s neuzavrenými elementami. To by som bral ako výhodu oproti XHTML.
Ale ne vždy, třebas tuhle prasárnu s neuzavřeným nadpisem specifikace HTML 4.01 neřeší:
<style> h1 {color: blue;} </style> <div> <h1>Nadpis </div> <p>OdstavecXMPP (Jabber) je postavený nad XML, přesto zobrazuje zprávy, i když nemá uzavřený kořenový tag (tedy ukončený rozhovor). Testování validity a průběžné zobrazování se totiž nevylučují a doporučení W3C jej nezakazuje, dokonce ani nedefinuje, jak má aplikace reagovat na chyby nahlášené XML parserem.
Hezky rozhovor. Je videt, ze p. Kosek ma odstup a dobry prehled o realite.
Se divim, ze tu jeste nepobiha a nepokrikuje zadne YAML kid ;-)
A XML zcela jiste neodejde, naopak — potreba ukladat informace, ktere svoji povahou neumoznuji bez znasilneni ulozeni do relacnich databazi, je cim dal vetsi. http://lists.nyphp.org/pipermail/talk/2007-August/022724.html
Na YAML jsme během rozhovoru narazili. Bohužel ta část padla za objeť přepisu. Byl to hodně dlouhý rozhovor, už tak vyšel na dva články. Musel jsem vybírat a některé věci bylo nutné vyškrtnout. Každopádně YAML je zajímavé téma a myslím, že se mu někdy budeme na Zdrojáku víc věnovat.
Asi mi neco uniklo, ale jsou snad na rootu max. povoleny limity na delku textu? Ja myslel, ze delka clanku se musi omezovat pouze u papirovych vydani, kde fyzicky dojde papir. Co ale dojde na webu, kdyz bude ten clanek delsi? Misto v DB nebo na disku? Nebo snad p.Kosek dal svoleni se zverejnenim pouze max.poctu znaku v clanku? Nebo to bylo kvuli casove tisni – IMHO si radsi pockam 1-2 dny na prepsani i toho posledniho odstavce, pokud je zajimavej.
Prakticky všechny webové magazíny mají nějaké doporučené rozsahy článků a Root ani Zdroják nejsou výjimkou (nahlédněte do veřejných pravidel k psaní článku tady na Zdrojáku nebo kdekoliv jinde). Vychází ze zkušeností s psaním a čtením textů na webu, nejde tedy o pravidlo daně nějakou technologií.
A S-expressions znate? :-)
1. vadi mi na nych nesymetricnost… to same co na YAMLu. Na XML vidim kde tag zacina a konci. Je to vic mista, ale je to pro me nejcitelnejsi format pro zapis hierarchickych dat, co jsem videl. Predstava vetsiho dokumentu typu ODF v formatech typu S-exps mi dobre nedela.
2. Jsou pro S-vyrazy ekvivalenty k nativni XML databazi, XPath, XSLT a XQuery? A pro jake jazyky jsou API? ja chapu, ze tohle je vsechno otazka implementace a ze neni duvod, proc by to same nemohlo byt. Ale me zajima, jestli to existuje ted, minimalne pro Javu nebo PHP. Aplikaci nepostavim na hezkem pocitu, ze by to slo….
Jestli XML nebo sexp mne v zásadě netrápí vzhledem k existenci funkčních konvertorů mezi XML a sexpy. Ale neudržím se:
1. Pokud autor sexpu nebyl prase, tak je konec vidět z odsazení. Kromě toho každý rozumný editor zobrazuje matchující závorky.
Co se týče většího dokumentu, tak je to otázka přístupu. Mně nedělá dobře dokument který začne tagem a skončí jeho párovým tagem na konci po tisíci řádkách textu obecně. Cokoliv zabírá více než obrazovku mám raději modulárně rozdělené na menší celky, a tam ten problém není. Naopak, na jednu obrazovku se toho vejde víc.
2. Možná by bylo lepší formulovat úlohy,které ty technologie řeší než jen jejich názvy, protože takhle člověk musí znát jak ty odkazované technologie, tak Lisp/sexpy, aby mohl odpovědět. Pokud si překládám XSLT jako transformace z jednoho sexpu do druhého pomocí nějakých pravidel, tak to dělá obecný Lispový program. Ostatní bych spekuloval, a klidně přiznávám že ani nemusí existovat – jen připomínám, že Lisp byl jedním z polí kde se provádělo dost pokusů s různými query jazyky a databázemi faktů – vizte třeba Norvigův PAIP nebo Grahamův On Lisp.
Pokud chcete obdobný dotaz opačným směrem, tak jaký je XML ekvivalent CL sexp zápisu #1=(foo :prev #1# :next #1#)?
Argumentace aktuálním stavem nástrojů mi nepřijde šťastná ve vztahu k YAMLu – jaké byly nástroje pro XML v roce jedna jeho existence? Nebo, jak bylo v článku, v PHP3?
Jenze u velkeho dokumentu sjedete dolu a vidite jen kaskadu uzaviracich zavorek. K cemu patri, to uz nevite.
Tohle je nerealny pozadavek. V realu se proste setkate s velkymi datu v jednom souboru a pokazde je rozsekat nemuzete.
Treba pripad, kdy pisu webovou aplikaci, ktera pracuje nad daty, ktera maji vsemoznou strukturu, jen ne takovou, aby se dala nacpat do tabulek a nebilo to do oci… (dokumenty v ODF, OOXML, DocBook, obecne treba kniha se sekcemi, kapitolami, podkapitolami etc…). Mohl byste se dneska zodpovedne rozhodnout postavit takovou aplikaci nad ulozistem, ktere by ta data ukladalo v S-expech? Cim byste se na ne dotazoval a jak by fungoval fulltext? Nerikam, ze to neni mozne, spis me zajima jestli ano… (jak je to u nich s jmennymi prostory a validovatelnost oproti nejakemu schematu?)
1. Měl jsem na mysli rozdělení i v rámci jednoho souboru. Ale uznávám, že to je otázka možného. Mimochodem, když mám ukončovací sérii sedmi </div>ů, tak to taky moc neřekne, ale chápu že to není problém XML jako takového.
2. Mám to chápat tak, že XML jako je základní forma dat ve které jsou za běhu? Takové ambice bych se sexpama jako řetězci textu asi neměl – spíš bych to viděl tak, že data jsou za běhu uložena v paměti ve vhodném formátu (třídy, seznamy, pole, hash tabulky) a sexpy slouží k jejich ukládání/odlévání a případné manuální editaci v lidsky čitelném formátu.
Jmenné prostory – nejsou problém (třeba v CL)
Validace – pokud je třeba, tak jako program, ale obecně se u sexpů až na souhlas závorek a exportovanost použitých tagů z jiných balíků neřešívá a nevím o ničem co by na to obecně existovalo a používalo se. Respektive jsem viděl nástroje, které řeší zda sexp odpovídá nějakému definovanému jazyku, ale zda je sexp pro daný účel v pořádku většinou pozná až ta aplikace co data načítá a používá.
No, takhle, ja sexpy sam moc neznam (Lispem se zabyvam asi mesic). Ale jsou mi velmi jasne jejich vyhody oproti XML (vysvetlim nize). A na vase konkretni namitky odpovedel jiz Tomas.
Obecne bych ale rekl, ze nepopiram uzitecnost XML pro popis dokumentu (tedy takove veci jako XHTML nebo DocBook). Ale to je tak cele, a tedy to nezahrnuje zdaleka vsechny aplikace mimo relacni databaze, jak jste uvedl na zacatku vlakna. Zejmena mi vadi aplikace XML typu vzajemna komunikace mezi pocitacovymi systemy a konfigurace, tj. tam, kde se lidska ruka vyskytuje zridka, pokud vubec. Neboli obecne ukladani semistrukturovanych dat. Na tyto aplikace jsou sexpy jednoznacne vhodnejsi, a to predevsim z techto duvodu:
1. Jsou kratsi zapis a lepe se parsuji (neni nutne hledat koncovy tag). Navic, na rozdil od XML, syntakticky nerozlisuji mezi entitami a atributy (a procesnimi instrukcemi, ale to uz je detail), a z toho vyplyvaji dalekosahle dusledky. Napriklad, jazyky ekvivalentni XPath, XQuery, XSLT, ktere zminujete, by pro sexpy byly daleko jednodussi, prave proto, ze nemusi resit tuto nesmyslnou dichotomii (ona smysluplna je, ale prave jen u dokumentu; tam se do atributu dava to, co zpracovava stroj, a do entit to, co bude cist clovek).
2. Dokazu si predstavit dobre navrzenou sadu lispovych funkci nebo maker, ktera muze prijmout cely sexpovy dokument, a okamzite ho zpracovat, nebo vytvorit nejakou jeho reprezentaci, podobnou napr. DOM. Tato reprezentace muze byt navic velmi flexibilne zavisla na konkretni domene. Tohle XML neumoznuje, protoze neni primo programovacim jazykem, a take tomu brani vyse zminena dichotomie mezi elementy a atributy. S timto nejsou spojene zadne bezpecnostni problemy – bylo by pomerne trivialni napsat funkci, ktera proveri dany sexpovy dokument vzhledem ke schematu (a tedy proveri, zda funkce v nem obsazene jsou z urcite bezpecne mnoziny funkci) – rozhodne trivialnejsi, nez napsat samotny XML parser. Pak uz je mozne jen napsat tyto funkce a cely dokument po zvalidovani spustit – voila, mate XML-like aplikaci bez nutnosti parsovani XML, prolezani DOM, a podobnych nesmyslu. Navic muzete ty funkce definovat tak, ze treba umoznuji priradit neco promenne, a tohle vam XML jako takove neda.
Na komunikaci mezi pocitacovymi systemy je XML celkem nakladne, to ano. Ale treba u takoveho Jabberu, kde je casto potreba zahrnout treba formatovany text je to fajn, protoze staci proste rozsirit XMPP o XHTML NS a mate porad konzistentni format.
Elementy vs. atributy. Rozhodne smysluplna vec, z hledisla semantiky. Kazdy z tech kontruktu se hodi na jiny typ dat. http://www.ibm.com/developerworks/xml/library/x-eleatt.html
Jinak to, co popisujete je fajn, ale asi sam vite, ze pri dnesnim stavu SW nastroju je to hudba daleke budoucnosti, jestli vubec… Do aplikace v PHP nebo Jave interpretr Lispu tahat nebudu a do S-vyrazu ta data musim nejak prevest, abych s nimi mohl pracovat jak popisujete, protoze nevim o spolehlivem nativnim S-exp ulozisti dat.
Diky za pekny rozhovor. Hodne lidi na pana Koska nadavalo, ze za CR na OOXML nakonec zaslal ANO. Jsem naopak rad, ze pan Kosek nebral schvalovani OOXML na lehkou vahu, ale ze se jim opravdu do podrobna zabyval.
Take se pridavam k podekovani za rozhovor i za praci pana Koska na standardizaci OOXML.
Díky, že jste pana Koska jako největší autoritu v oblasti XML u nás takhle vyzpovídal!
> Otázka: Ale na webu se prosadil JSON. A to na mnoha místech, kde vévodilo XML.
> Odpověď JK: Na malé pokusy a hraní to bylo úžasné. Ale jakmile začnete JSON používat v masovém měřítku, musí se řešit problémy, např. že eval není bezpečný a měl by se tam vložit parser. Pak se zjistí, že by bylo dobré data validovat, tak se přidá schéma. Takže se udělá úplně to stejné, co už v XML je.
Můj názor: Co je tohle za nesmysly? Proč by eval neměl být bezpečný? Proč by se měla odpověď od serveru validovat? Když posílám dotaz svému serveru, tak snad vím, co jsem tam naprogramoval a co mi přijde za odpověď.
V dotazu se přeci jednalo o použití formátu JSON na webu, ne při přenosu dat mezi kdovíjak velkými aplikacemi. Já používám JSON bez obtíží a jsem za něj moc rád (jednoduchost a rychlost zpracování, malé množství dat, velká podpora formátu).
Používáním JSON pouze z vlastních dat je mýtus. Jednak služby, které předávají data dalším serverům, rostou jako houby po dešti (byť se tam následně musí nějak řešit komunikace napříč doménami) a pak i samotné omezení v komunikaci na vlastní server je již passé.
V nových verzích prohlížečů se totiž pomalu objevuje ajaxová komunikace napříč doménami. Načítání JSON pomocí evalu byl opravdu jen jednoduchý trik, který pro jeho větší rozšíření (které nastává) nebude stačit. To je ostatně i důvod proč autor formátu JSON, Douglas Crockford, již dnes doporučuje používat alespoň javascriptový parser (který sám navrhl a napsal) namísto funkce eval.
Nevím, proč by omezení v komunikaci na vlastní server "je již passé". Držíme se toho, co se používá dnes, ne toho, co nám výrobci "slibují pro příští pětiletku" a většina používaných prohlížečů komunikaci na server mimo doménu blokují, takže se musí nějak řešit "komunikace napříč doménami".
Můj názor zní, že ona zmíněná komunikace "komunikace napříč doménami" nemusí být jen prostý tunel na mém serveru, může odpověď parsovat, ověřit, zpracovat a pak teprve poslat data klientu. Na vlastním serveru mám totiž mnohem větší kontrolu nad tokem dat a zásobu odladěných knihoven než na klientu.
Když udělám tenhle jednoduchý mezikrok, můžu už na klientu důvěřovat poslaným datům i bez ověřování.
Tak nejen slibují. Takový to IE8 představil už loni. W3C finišuje standardizaci tohoto řešení a od ostatních čekám, že do jednoho roku tu budou podporovat rovněž.
Stačí se rozhlédnout, jak se JSON často používá dnes a slova termínům "bezpečnostní díra" nebo "koledování si o problém" se prostě nelze vyhnout.
od te doby co MS Office jede taky na XML verim, ze se opravdu tento format rozsiri. Jako vzdy MS umel bravurne zuzitkovat stavajici technologii a vyuzit ji. Coz se o nekterych OS projektech rici neda. Vcera jsem si zkusmo po delsi dobe stahnul OO.org a smal jsem se az jsem za bricho popadal ….
U nas ve firme ma rada lidi krome MSO nainstalovany i OOo, protoze nektere veci holt MSO neumi. (Ale nemusim se MS smat jak 12 lety skolak – "odbornik" na IT, ktery – jak vas tipuju – ani pri psani neumi pouzivat styly.)
A mimochodem, kdyz se jede z kopce, tak se nemusi slapat (aneb o technologii to neni)
A to jsem ani neuvedl, ze jsou s MSO daleko vetsi provozni problemy (shrnuto ze statistiky za stredni a vychodni evropu)
vzhledem k tomu ze MSO se narozdil od OO opravdu realne pouziva, nemaji tyto statistiky smysl. Styly pouzivat umim, je mi 33 ne 12. Nicmene nad LaTeX stale neni …
Zda se, ze tu zacina flame. No to je moje a tak se hned pripojim – taky se mi zda ze vsech wordprocesoru nejlepsi latex, ale na druhou stranu, kdyz uz mi prijde nejaky zlovolny dokument formatovany nejmenovanym mezinarodnim kartelem, oofice si prijde na svy. Kupovat si MSO mi pripada moralne nevhodne.
A abych byl zcela ferovy, takove ty vyplnovaci formulare ve wordu nekdy byvaji zrejme ulozeny pomoci DSA-128, protoze pri nejlepsi vuli jsou nekdy posunute.
Po shrnutí aktivit pana Koska i z rozhovoru mám pocit, že pan Kosek je ryzí teoretik. Nechci nijak zpochybňovat jeho znalosti ani činnost. Jen by mě zajímalo, kdy naposled vytvářel nějaký web.
A možná obecně. Kolik lidí, kteří píší standardy, se v oboru pochybuje i prakticky. Jestli je tam někdo, kdo několikrát do měsíce navrhne nějakou šablonu, staví web. A ne kvůli ověření teorie. Něco ryze komerčního, nějaké stránky na zakázku. Zbývá jim na to čas? Tvoří standardy web designeři, web architekti nebo jsou to jen pisálci, přednášející a "akademici"? Jestli se pak ti lidé, kteří vytvoří standard, třeba někdy chytnou za hlavu, jaký zmetek vlastně napsali a jak jsou některé věci nedomyšlené, pitomě nedotažené. To se totiž bez praxe asi ani zjistit nedá.
Konkrétně já kroutím hlavou nad CSS. Pozicování, float, padding mimo width atd atd. Ten box model je jedna velká prasárna. To nedal dohromady člověk, který s tím pak potřebuje dnes a denně pracovat a řešit reálné situace. (A nenarážím teď na různe interpretace browsery. To je jiná, i když neméně bolestivá, otázka.)