35 komentářů k článku Jiří Kosek: XML už je všude:

  1. radino

    XML a JSON
    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..

    1. Tomas Z.

      Re: XML a JSON

      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?

      1. radino

        Re: XML a JSON
        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..

    2. webdev

      Re: XML a JSON
      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.

  2. onyx

    Zobrazování XML v prohlížečích
    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.

    1. vlabra

      Re: Zobrazování XML v prohlížečích
      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.

      1. Jozef Benko

        Re: Zobrazování XML v prohlížečích
        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.

        1. Bubák

          Re: Zobrazování XML v prohlížečích

          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
          
    2. Sten

      Re: Zobrazování XML v prohlížečích
      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.

    1. Martin HassmanAutor příspěvku

      RE: Jiří Kosek: XML už je všude
      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.

      1. Anonym

        RE: Jiří Kosek: XML už je všude
        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.

        1. Martin HassmanAutor příspěvku

          RE: Jiří Kosek: XML už je všude
          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í.

      1. smilelover

        RE: Jiří Kosek: XML už je všude
        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….

        1. Tomas Z.

          RE: Jiří Kosek: XML už je všude
          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. smilelover

            RE: Jiří Kosek: XML už je všude

            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. Tomas Z.

              RE: Jiří Kosek: XML už je všude
              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á.

        2. JS

          RE: Jiří Kosek: XML už je všude
          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.

          1. smilelover

            RE: Jiří Kosek: XML už je všude
            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.

  3. Petr

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

  4. MazeGen

    Díky za rozhovor
    Díky, že jste pana Koska jako největší autoritu v oblasti XML u nás takhle vyzpovídal!

  5. slady

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

    1. Martin HassmanAutor příspěvku

      Re: JSON
      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.

      1. slady

        Re: JSON
        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í.

        1. Martin HassmanAutor příspěvku

          Re: JSON
          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.

  6. mat

    jo a rozsirovat se bude
    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 ….

    1. martin

      Re: jo a rozsirovat se bude
      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)

      1. martin

        Re: jo a rozsirovat se bude
        A to jsem ani neuvedl, ze jsou s MSO daleko vetsi provozni problemy (shrnuto ze statistiky za stredni a vychodni evropu)

        1. Anonym

          Re: jo a rozsirovat se bude
          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 …

          1. mirozbiro

            Re: jo a rozsirovat se bude
            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.

  7. mega

    Teorie vs praxe
    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.)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2944