Vlákno názorů k článku
Jiří Kosek: XML už je všude

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.

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?

1. Pokud autor sexpu nebyl prase, tak je konec vidět z odsazení. Kromě toho každý rozumný editor zobrazuje matchující závorky.

Jenze u velkeho dokumentu sjedete dolu a vidite jen kaskadu uzaviracich zavorek. K cemu patri, to uz nevite.

Cokoliv zabírá více než obrazovku mám raději modulárně rozdělené na menší celky, a tam ten problém není.

Tohle je nerealny pozadavek. V realu se proste setkate s velkymi datu v jednom souboru a pokazde je rozsekat nemuzete.

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.

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.