Názory k článku
Jiří Kosek: XML už je všude

JSON je hlavne format, ktory je urceny na serializaci.

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.

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>Odstavec

XMPP (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.

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.

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? :-)

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?

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.

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)

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.)