Komentáře k článku

XSLT – jazyk budoucnosti

Protože je dnes stále více dat dostupných v XML, vznikla potřeba jazyka, který umožní jednoduše popsat způsob převodu mezi různými formáty založenými na XML. Právě XSLT je jazyk, který umí jednoduše popsat, jak se má dokument XML převést na dokument XML s jinou strukturou, případně do podoby stránky HTML nebo dokonce do čistého textu.

Zpět na článek

65 komentářů k článku XSLT – jazyk budoucnosti:

  1. Peter

    XPath 2.0 / XSLT 2.0

    Dobry den,

    su v knihe opisane aj nove vlastnosti v XPath 2.0 a XSLT 2.0? Rad by som si trochu doplnil znalosti ucelenejsim sposobom a kniha v cestine by bola celkom fajn. Z obsahu to nie je celkom zrejme.

    1. fos4

      Re: XPath 2.0 / XSLT 2.0

      K XSLT existuje jeste rozsireni exslt. Dokumentace na adrese: http://exslt.org/

      Zjisteni jestli uz dany XSLT procesor umi exslt lze zjistit pomoci fce hasExsltSupport().

      $proc = new XSLTProcessor;
      if (!$proc->hasExsltSupport()) {
          die('EXSLT support not available');
      }
      ...
    2. Jiří KosekAutor příspěvku

      Re: XPath 2.0 / XSLT 2.0

      XPath2/XSLT2 popsáno není, protože PHP pro XSLT používá knihovnu libxslt, která podporuje pouze verzi 1.0 (+ rozšíření EXSLT, jak píše kolega níže) a podpora 2.0 se v dohledné době nechystá.

      Zajímají-li vás novinky v XSLT2.0 dopo­ručuji následující školení http://www.cleverlance.cz/…i/modal.aspx?…

      Nebo si můžete přečíst následující knížku
      http://www.amazon.com/…p/0470192747
      (důležité je 4. vydání, které popisuje finální verzi XPath/XSLT 2.).

  2. pepazdepa

    lehce offtopis - TEI/Docbook

    diky za dobry clanek!

    jedna otazecka: mam udelat knihovnu textovych dokumentu, ktere obsahuji citace, basne, pisne, proste klasicky knizni texty. nejdrive jsem myslel na docbook, ale jen tam trochu postradam tagy napriklad na basen apod. padl mi do oka project TEI (coz je presne xml na spravu textu). meli byste nejake poznamky prosim? docbook nebo TEI? co by bylo dobrou cestou?

    predem dekuji.

    1. Jiří KosekAutor příspěvku

      Re: lehce offtopis - TEI/Docbook

      Osobně se mi značkování TEI líbí mnohem méně než DocBook, ale je speciálně navržené pro přesně pro typy dokumentů, co píšete. Takže pro vaše potřeby bude asi lepší TEI.

      Existuje i pracovní verze rozšíření DocBooku, která je určena speciálně pro vydavatele knižních textů:

      http://www.oasis-open.org/…/tc_home.php?…

      Jaké nové elementy jsou přidány je vidět přímo ve schématu:

      http://docs.oasis-open.org/…blishers.rnc

  3. josef

    XSLT :-/

    Muze mi nekdo vysvetlit nejakou zasadni vyhodu XSLT pri zpracovani XML souboru?
    XSLT syntaxe mi prijde strasne tezkopadna. Mam pocit, ze jeji tezkopadnost je dana zejmena snahou napsat jazyk deklarativne, tak by sam mel XML strukturu. Ale k cemu to je? Mate nekdo zkusenost, kdy se vam to opravdu hodilo?
    Daleko vic bych uvital , kdyby se vytvoril/stan­dardizoval nejaky skriptovaci jazyk (treba JavaScript) + knihovna pro zpracovani XML, kterou by vsechny nastoje, ktere dnes umi XSLT (take) zvladaly.
    Obecne mi deklarativni programovani moc k srdci neprirostlo. Rozhodne davam treba prednost ruby rant-u pred antem.
    Nechci zde vyvolat nejaky flamewar, ale zajimaji me nejake zkusenosti z praxe.
     Diky

    1. Jiří KosekAutor příspěvku

      Re: XSLT :-/

      Nemám čas to nějak dlouze rozebírat, ale hlavní výhody vidím v:

      1. uzké integraci s dotazovacím jazykem XPath, XSLT operuje přímo s datovým modelem XPath, používá XPath pro zápis všech výrazů, … – není tak potřeba pořád se přepínat a konvertovat mezi typy XPathu a daného programovacího ja­zyka

      2. mechanismus rekurzivního průchodu stromem a volání šablon – to si jinak musíte programovat sám a pokud do toho zahrnete všechno, co umí XSLT – režimy, priority, zabudované šablony, … – není to úplně triviální

      3. pomocí XSLT většinou generujete XML nebo HTML výstup – ten lze do kódu šablony vložit přímo bez nutnosti escapování jako v klasických jazycích

      Pro složitější aplikace, které jsem dělal, je kód v XSLT 2.0 3–10× kratší než v klasickém procedurálním jazyce, rychlost vývoje a chybovost kódu tomu zcela odpovídá.

      1. josef

        Re: XSLT :-/

        Dekuji za odpoved. V mnoha ohledech souhlasim. XSLT je nekdy opravdu efektivni.
        ackoli jsem to v puvodnim prispevku nezminil, tak s XSLT mam problem zejmena v situacich kdy ta transformace neni trivialni – kdy struktura XML neodpovida strukture vystupu, nebo zpracovani vyzaduje vice pruchodu ( kniha s obsahem,…).
        Je to vse urcite o praxi, s XML nepacuji prilis casto, ale XSLT nejde pouzit na takoveto obcastne „zbastleni“ neceho co je zrovna jednorazove potreba. Pokud to chce clovek/ja ;-) pouzit, tak musi proniknout nekdy pomerne hluboku do tohoto jazyka.
        To se mi v proceduralnich jazycich nestava ;-)

        1. fos4

          Re: XSLT :-/

          XSLT používáme ve firmě už pár let a nedáme na něj dopustit. Jedinou nevýhodu kterou vidím je celkem pomalá transformace která při velkých datech trvá celkem dlouho (příklad e-shop a vypsaní více produktů s hodně informacemi – nezbývá nic jiného než cachovat).
          Skvělou podporu XSLT syntaxe ma PSPad.

          1. Jiří KosekAutor příspěvku

            Re: XSLT :-/

            Moje zkušenost je, že XSLT není pomalé, ale často je nevhodná architektura, kde se XSLT volá. Někdy bývají i transformace samy o sobě napsané neefektivně.

            Jinak bez použití vyrovnávacích pamětí by dnes málo která webová aplikace ustála větší zátěž, bez ohledu na to, zda používá XSLT, databázi nebo cokoliv jiného.

            1. T.oo.M

              Re: XSLT :-/

              Souhlasím, že největším problémem je vždy samotný návrh šablony. Pamatuji si na jeden případ, kdy jednoduchou úpravou šablony se zkrátila doba zpracování asi o 97%. Jednalo se o převod ploché struktury do hierarchické s velkým množstvím odkazování na elementy definované v úvodu xml.

        2. Jiří KosekAutor příspěvku

          Re: XSLT :-/

          Vidíte, mě naopak přijde, že věci jako generování výstupu s odlišnou strukturou nebo více průchodů při zpracování jsou v XSLT mnohem jednodušší, než to psát v nějakém klasickém jazyce s využítím DOM apod.

          XSLT pracuje na odlišném modelu, než konvenční procedurální program. Na školení vždy říkám, že je potřeba si na XSLT zvyknout a přeskupit neurony v mozku tak, aby mysleli v duchu XSLT/XPath. ;-)

          1. josef

            Re: XSLT :-/

            Je to asi opravdu o zkusenostech s jazykem.
            Jeste bych se zeptal na otazku nadhozenou v mem prvnim prispevku. Napada Vas k cemu je vyhodne, ze ma XSLT XML strukturu. Chapu vyhodnost pro tvurce XSLT knihoven, kteri tak potrebuji jen jeden parser, ale co to prinasi pozitivniho programatorovi ? Znate nejake pouziti dynamicke prace s XSLT skripty?

            1. Jiří KosekAutor příspěvku

              Re: XSLT :-/

              Výhod to má mnoho, např.:

              – lze přímo do transformace kopírovat fragmenty XML/HTML, které má šablona generovat, bez nutnosti nějakého escapování

              – s předchozím souvisí to, že v mnoha případech lze použít zjednodušenou syntaxi transformace (http://www.kosek.cz/…vnistyl.html#…), kdy je celá transformace v podstatě jen kostra HTML, které se má generovat, s doplněnými pár instrukcemi XSLT

              – automaticky je zaručeno, že výstup bude well-balanced (well-formdness zaručena není, transformace XSLT může teroreticky vygenerovat dokument s více kořenovými elementy) – chyby ve spárování a ukončování elementů je tak odhalena brzy, ještě před spuštěným transformace

              – se zdrojáky XSLT lze pracovat automaticky pomocí XSLT – v praxi se to používá překvapivě často, pár příkladů např. viz http://www.xml.com/…05/xslt.html

              – a jistě je i mnoho dalších důvodů, které mě zrovna teď nenapadají

              1. V.Novák

                Re: XSLT :-/

                Řekl bych, že hlavní příčinou nechuti k XSLT je „neprogramátorský“ vzhled. Přece jenom otvírací a uzavírací tagy, parametry přes atributy… no, nepůsobí to jako program.

                Možná kdyby se to dalo psát v něčem co by mělo méně toho syntsktického balastu a pak zpreprocesit do XSLT a vykonat, dost odporu by odpadlo. Samozřejmě by to byla pomůcka jen pro příležitostného kodéra XSLT – ale pro koho je to denní chleba, ten si zkrátka musí zvyknout.

                1. Jiří KosekAutor příspěvku

                  Re: XSLT :-/

                  Můžete používat XQuery, to umí v podstatě totéž co XSLT 2.0, akorát to nemá mechanismus šablon a instrukce pro seskupování.

                2. Kit

                  Re: XSLT :-/

                  Jak jsem si nedávno vyzkoušel, není velký problém si XSLT vygenerovat LISPem. Ovšem je nutné si uvědomit, že bez uvozovek to nepůjde.

  4. Jakub Vrána

    SimpleXML

    V závěru článku je uvedeno, že SimpleXML nedovoluje přistupovat ke všem informacím v XML a že na rozdíl od DOM nedokáže data modifikovat. Ani jedno není pravda.

    Tou nepřístupností všech informací se asi naráží na nedokonalou podporu jmenných prostorů v SimpleXML. Pracovat nicméně lze i s takovými dokumenty, byť trochu nepohodlněji přes metodu xpath. Pořád se mi to ale zdá pohodlnější než DOM.

    SimpleXML dovoluje XML dokument i modifikovat, lze přidávat další elementy a upravovat stávající, používá se k tomu stejně intuitivní API jako pro čtení. Upravený dokument lze pak zapsat metodou asXML.

    1. Jiří KosekAutor příspěvku

      Re: SimpleXML

      Jakube, tobě to SimpleXML nějak přirostlo k srdci a nedáš na ně dopustit. Myšlenka SimpleXML je pěkná, ale ta implementace v PHP je naprosto zbastlená, kromě jednoduchý use-case je to opravdu nepoužitelné.

      Kromě dost nepohodlné práce se jmennými prostory je problém v nulové podpoře smíšeného obsahu (tu lze obejít pouze konverzí na DOM). Samozřejmě, pokud někdo používá dokumenty XML bez jmenných prostorů a bez smíšeného obsahu, odvede SimpleXML dobrou službu.

      Obejití špatní podpory jmenný prosotrů přes XPath je v knize popsáno, nicméně to, že se nedostatek API řeší přes XPath mi nepřijde jako omluva pro SimpleXML. Principiálně to je špatně navíc, pokud by aplikace výběrů dělala více, projeví se v tomto případě výkonostní penalta daná nutností XPath výrazy naparsovat a poté provádět, na rozdíl od jednoduchého přístupu k dětskému elementu pomocí metody.

      Ad modifikace – pokud jsem něco nepřehlédl, lze jen přidávat nové dětské elementy nakonec seznamu dětí. Takže nejde vytvořit smíšený obsah ani nejde provádět jiné modifikace – přidání nového elementu mezi existující, či smazání elementu.

      1. Jakub Vrána

        Re: SimpleXML

        Je pravda, že vložit element doprostřed stávajících nejde. Smazat element lze ale pomocí intuitivního unset($xml->a[0]) a přidat na konec pomocí $xml->a[] = „text“.

        Absence práce se jmennými prostory bez XPath je smutná, v PHP by se k tomu dala použít syntaxe $xml->{„dc:title“}.

          1. Jakub Vrána

            Re: SimpleXML

            Aha, nebo správnější $xml->children(‚http:/­/purl.org/dc/e­lements/1.1/‘, false). Druhý parametr přibyl v PHP 5.2.0.

  5. Pavel

    temna budoucnost

    Dobry den,

    s XSLT jsem se setkal jednou, protoze sem potreboval zmenit nejaky protokol,ktery v tom byl udelany. Z XSLT se nejakym zpusobem volaly funkce javaskriptu, ktere se pak nejak oklikou zpetne dostavaly k souboru se zpracovavanym xml, a prochazely je asi pres DOM. Byla jedna z nejzamotanejsich veci, ktere sem kdy potkal.Mozna to bylo pokud nestastne pouzite.

    Nejsem na ten jazyk specialista, ale jdou v nem vubec provadet matematicke vyrazy nebo prevest utc cas na lokalni cas, formatovat cislo na desetinna mista nebo prevest dobu behu v sekundach na hh:mm:ss ?

    Nevim proc kdyz mam v pocitaci procesor ktery zvladne miliony operaci za sekundu, tak musim pracovat s jazykem, ktery me vpodstate k nicemu nepusti.

    Je to mozna dobre na najeke uplne koncove preformatovani, kde uz se nic nepocita. Otazka je jestli se takove veci nedaji resit radsi nejakou knihovnou nez zrovna celym jazykem.

    Co cross refence a debugging ?

    zdravi, Pavel

    1. Stefan

      Re: temna budoucnost

      >>Nejsem na ten jazyk specialista, ale jdou v nem vubec provadet matematicke
      >>vyrazy nebo prevest utc cas na lokalni cas, formatovat cislo na desetinna
      >>mista nebo prevest dobu behu v sekundach na hh:mm:ss ?

      Ano, vsetko popisane sa da. Vsetko ostatne sa da velmi jednoducho doprogramovat.

      Najvacsia vyhoda XSLT spociva v maximalnom oddeleni kodu od struktury a dizajnu. Pri spravnom nasadeni usetri XSLT cele tyzdne vyvoja.

    2. Jiří KosekAutor příspěvku

      Re: temna budoucnost

      Transformace, která volá nějaký externí kód v JS či v Javě, je v 90% znakem toho, že její vývojář neuměl XSLT a tak z něj utíkal k jazykům, které zná.

      Z toho co píšete, umí XSLT/XPath vše. Koneckonců XSLT je turingovsky úplné, takže v něm jde teoreticky naprogramovat vše. Samozřejmě, pokud byste ptřeba chtěl z XSLT komunikovat s databází nebo po síti (mimo HTTP GET, to umí funkce document()), je potřeba využít nějakou extenzi. Ale ohledně výpočtů, práce s řetězci atp. lze realizovat vše.

      Nevím, co myslíte cross referencemi a pro ladění XSLT existuje mnoho pohodlných debuggerů. Např. http://www.oxygenxml.com/…ebugger.html

      1. Pavel

        Re: temna budoucnost

        Nevim proc ten vyvojar od toho utekl,k JS, ale ja sem vpodstate skoncil stejne.
        Protoze bylo jednodussi a rychlejsi sahnout po necem co uz aspon trochu znam.

        Jedna vec je dokazat ze neco jde napsat a druha, jestli usili vyvolane pouzitim tohoto jazyka neprevazi usily timto jazykem usetrene.
        Co enumerace,uzi­vatelske typy ,pole a asociativni pole ?
        Dostanete se k ordinalni hodnote znaku retezce a retezci z ordinalni hodnoty ?

        Cross reference jsou spis vec vyvojoveho prostredi. Myslim tim dostat se u pouzite promenne na nejaky vypis vsech jejich pouziti, nejlepe s oznacenim jestli se jedna o cteni nebo/a zapis. Nicmene to,jestli je dane pouziti read/write jsem nenasel ani ve Visul Studiu, to uz bych toho asi chtel moc.

        Je pravda ze sem se tim potkal tak cca pred 4 rokama, mozna uz to nejak vylepsily.Ja sem s tim zapasil ve VIMu, debugovani pres alerty v javascriptu,takze to nebylo to prave orechove.

        zdravi, Pavel

        1. Jiří KosekAutor příspěvku

          Re: temna budoucnost

          Jedna vec je dokazat ze neco jde napsat a druha, jestli usili vyvolane pouzitim tohoto jazyka neprevazi usily timto jazykem usetrene.

          Je známá věc, že lepších výsledků se většinou dosáhne tím, že programátor píše v jazyce, který dobře ovladá, než kdyby psal v jiném jazyce, který je pro danou úlohu vhodnější, ale programátor jej nezná dobře.


          Co enumerace,uzi­vatelske typy ,pole a asociativni pole ?

          K čemu to v XSLT potřebujete? Data si můžete ukládat do libovolné struktury XML. Pokud chcete navíc silnou typovou kontrolu můžete použít plnou verzi XSLT 2.0.


          Dostanete se k ordinalni hodnote znaku retezce a retezci z ordinalni hodnoty ?

          string-to-codepoints()
          codepoints-to-string()


          Cross reference jsou spis vec vyvojoveho prostredi. Myslim tim dostat se u pouzite promenne na nejaky vypis vsech jejich pouziti, nejlepe s oznacenim jestli se jedna o cteni nebo/a zapis.

          Dobré XML IDE jako oXygen tohle umí. A proměnné v XSLT jsou určené jen pro čtení, takže tam tenhle problém odpadá ;-)

          1. Pavel

            Re: temna budoucnost

            K čemu to v XSLT potřebujete? Data si můžete ukládat do libovolné struktury XML. Pokud chcete navíc silnou typovou kontrolu můžete použít plnou verzi XSLT 2.0.

            Po silne typove kontrole uplne netouzim, ale rozhodne mam radsi kdyz u promenne vim ze je to double, a nikdy tam nic jinyho nebude.
            Enumerace a uzivatelske typy zlepsuji citelnost.

            V programovani taky hraje roli, kolik kodu se vam vejde na jednu obrazovku.
            Je celkem rozdil jestli koukate 25 radku nebo nebo rejdite scrollbarem na 250.
            Zapis v XSLT neni z nejkratsich.

            Dobré XML IDE jako oXygen tohle umí

            Kdyz si do nejake vetve xml neco ulozite, jak to IDE ukaze mista, kde se ta vetev pouziva pro cteni? Kdyz mam promennou asociativni pole, tak me IDE ukaze vsechna mista kde je primo pouzite (pokud se priradi do dalsi promenne odkazem, tak to samozrejme pada, ale najdete aspon to prirazeni).

            A proměnné v XSLT jsou určené jen pro čtení, takže tam tenhle problém odpadá ;-)

            Tomu my rikame konstanty :)

            Jak je to zpracovanim nekolika xml souboru najednou?

            zdravi, Pavel

            1. Jiří KosekAutor příspěvku

              Re: temna budoucnost

              <i>Po silne typove kontrole uplne netouzim, ale rozhodne mam radsi kdyz u promenne vim ze je to double, a nikdy tam nic jinyho nebude.</i>

              <xsl:variable name=„cislo“ select=„10“ as=„xs:double“/>

              <i>V programovani taky hraje roli, kolik kodu se vam vejde na jednu obrazovku.
              Je celkem rozdil jestli koukate 25 radku nebo nebo rejdite scrollbarem na 250.
              Zapis v XSLT neni z nejkratsich.</i>

              Pokud používáte XSLT na transformace XML, garantuji vám, že v 95% případů bude kód XSLT kratší než srovnatelný kód třeba v Javě + DOM.

              <i>Kdyz si do nejake vetve xml neco ulozite, jak to IDE ukaze mista, kde se ta vetev pouziva pro cteni? Kdyz mam promennou asociativni pole, tak me IDE ukaze vsechna mista kde je primo pouzite (pokud se priradi do dalsi promenne odkazem, tak to samozrejme pada, ale najdete aspon to prirazeni).</i>

              To si asi nerozumíme, vy si do proměnné můžete uložit kousek XML a v něm mít třeba celý záznam, hash tabulku, atp. Pracujete pak s proměnnou, takže podle toho vám to funguje i v IDE.

              <i>Jak je to zpracovanim nekolika xml souboru najednou?</i>

              Už XSLT 1.0 mělo funkci document(), kterou šlo načítat další dokumenty během transformace. Ve verzi 2.0 přibyly další funkce doc(), collection() a unparsed-text() – posledně jmenovanou lze číst i ne XML data.

              1. Pavel

                Re: temna budoucnost

                OK. Nechame pracovat cas, uvidime kolik lidi u toho zustane a kolik od toho utece :)

                zdravi, Pavel

              2. Pavel

                Re: temna budoucnost

                Jeste jedna provokace.
                Jak si v XSLT odstipnete dalsi vlakno ?
                Ma to nejaky princip zamykani pri pristupu z vice vlaken ?
                Co xslt a 2,4,8 a 16 jader ?
                Co jazyk budoucnosti na paralelismus (podud se nestane neco zvlastniho, tak v nem je budoucnost) ?
                Co vypocet XSLT na GPGPU ?

                zdravi, Pavel

                1. Jiří KosekAutor příspěvku

                  Re: temna budoucnost

                  Proboha proč bych se měl v XSLT starat o takové věci jako jsou vlákna? V XSLT popíšete transformaci jednoho XML na druhé XML/HTML a jak ji daný procesor provádí – jestli na jednom jádře nebo paralelně na 100 jádrech – je jeho problém, to nemá žádný vliv na můj XSLT kód.

                  Jinak Intel má například vlastní XSLT procesor, který transformaci automaticky provádí paralelně na více jádrech a pouze pak správně složí výsledek.

                  1. Pavel

                    Re: temna budoucnost

                    Kdyz se o neco starate, vetsinou z toho vytahnete vic, nez kdyz se o to nestarate :)

                    Mate distribuovany XSLT transformator, ktery vyuzije treba 10 pocitacu najednou ?

  6. Borek Bernard

    E4X (titulek musí být minimálně 4 znaky dlouhý)

    Chtěl bych se zeptat autora článku, jestli někdy pracoval s E4X (v JavaScriptu nebo ActionScriptu) a jaký na něj má názor. Schopnosti dotazování i zápisu mi připadají dobré (můžu napsat např.

    var myXml = <example attribute=„value“ />

    bez escapování) a aspoň mně osobně vyhovuje, že deklarativní zápis / dotazování můžu míchat s procedurálním kódem (podmínky, cykly apod.)

    Ptám se obecně, chápu, že v PHP nic jako E4X není.

    1. Jiří KosekAutor příspěvku

      Re: E4X (titulek musí být minimálně 4 znaky dlouhý)

      Osobně si myslím, že standardní DOM je snad nejhůře použitelné stromové API, co kdy spatřilo světlo světla. Osobně mi jako pro programátora nejvhodnější přijdou API právě jako E4X v Javascriptu neboo XDocument a LINQ to XML v .NETu 3.5 (VB.NET umí stejně jako Javascript XML literály bez escapování, C# bohužel ne).

      Byl jsem docela zklamaný, když se do poslední verze ECMAScriptu E4X nedostalo. Myslím, že nechuť k XML, kterou někteří weboví vývojáři mají, a přísun třeba k JSONu, jsou dány hlavně tím, že Javascript v prohlížeči nenabízí pohodlnou práci s XML. Přece jen DOM je dnes naprosto překonané rozhraní. Byl navržen pro aplikace, které potřebují poměrně verně reprezentovat vnitřní strukturu XML, jako jsou třeba editory XML. Většina aplikací však potřebuje mít hlavně možnost pohodlně a elegantně data číst, a tady má DOM dost co dohánět.

  7. Trm

    XSLT = jazyk pro zoufalce

    No, kazdy, kdo nejakou domu pohlehl modnimu trendu zvanemu XML asi zabredl u XSLT. A kazdy, kdo delal neco vetsiho brzo zjistil, jaka hruza to je. Zkouseli jste nekdy psat rekurzivni sablony? Vypada to ohromne prasacky, ze to snad ani nejde popsat. Takze, na blbustky dobry, na cokoliv rozumnyho, naprosto nepouzitely, ostatne jako vetsina ,,modernich technologii“.

    1. Jiří KosekAutor příspěvku

      Re: XSLT = jazyk pro zoufalce

      A myslíte, že by lidstvu stačilo zůstat u strojového kódu, nebo by bylo lepší vrátit se až k pazourku?

  8. xy

    xml moderni

    musim nakonec souhlasit s nazorem ktery jsem sam povazoval za trapny, ale xml dnes opravdu uz neni moderni, naopak je to spis cosi prehistorickeho

    1. Jiří KosekAutor příspěvku

      Re: Zajímavou alternativu podle mě představuje Scala

      Scala je moc pěkný jazyk, ale složitější transformace XML bych v tom psát nechtěl. Na jednoduchém případě vypadá vše jednoduše, ale v praxi si nevystačíte s pár šablonami – potřebujete režimy, priority, import – a to byste si musel ve Scala napsat vše sám, XSLT to už má v sobě přímo zabudované.

      Z odkazované dokumentace to na mě působí, že Scala nemá plný XPath, jen jednodušší dotazovací jazyk, to mi taky přijde škoda. A navíc samotná odkazovaná dokumentace byla z XML do HTML převáděna pomocí XSLT ;-)

      1. Inkvizitor

        Re: Zajímavou alternativu podle mě představuje Scala

        Asi by to chtělo tu knihovnu poněkud vylepšit, s tím souhlasím. Největší oříšek z hlediska transformace bych viděl v těch importech, to se s pattern matchingem poněkud tluče.

  9. pravdokop

    moje zkušenost

    Před pár lety jsem napsal pár aplikací v XSLT a můj záver je ten, že na jednoduché transformace XML do XML/HTML/textu se to docela hodí. Složitější věci a zvláště měnící strukturu dat bych v tom už ale nikdy nedělal. Za tu námahu to nestojí.

    V poslední době jsem objevil JSON a musím říci, že mi na většinu aplikací přijde efektivnější, úspornější i rychlejší než XML.

    1. Jiří KosekAutor příspěvku

      Re: moje zkušenost

      Složitější věci a zvláště měnící strukturu dat bych v tom už ale nikdy nedělal. Za tu námahu to nestojí.

      A nechcete poslat nějaké zadání. Já že bych napsal řešení v XSLT a vy ve vašem oblíbeném jazyce, aby bylo vidět, co je namáhavější a složitější ;-)

      1. Jan Tichý

        Re: moje zkušenost

        OK, tak třeba co já vím, problém obchodního cestujícího? To by mělo XSLT zvládnout, je to přece turingovský úplný jazyk ;). Jdu do toho proti vám s PHPčkem ;).

        1. Jiří KosekAutor příspěvku

          Re: moje zkušenost

          To XSLT samozřejmě zvládne, ale kolega výše psal něco o složitých transformacích XML dat měnících strukturu. Takže očekávám zadání typu, vstup je tohle XML, je potřeba z toho udělat takový a takový výstup podle těchto a těchto pravidel.

          Jinak na obchodního cestujícího bych vám místo PHP doporučil spíše něco jako Haskell ;-)

          1. Pavel

            Re: moje zkušenost

            nemusite zkouset nic slozityho, v c# sem narazil u celkem jednoducheho problemu a to je prirozene trizeni (Natural Order Numerical Sorting),ktere pokud se v retezci vyskytnou cisla, tak radi podle techto cisel.Takze file2 je pred file12,protoze pred tim cislem jsou retezce stejne a 2 je mensi nez 12.
            Pocatecni nuly se ignoruji, tedy f02 je pred f00003.
            Posloupnost cisel v retezci samozrejme muze byt libovolne dlouha.
            Krome toho to muze mit parametr jestli se rozlisuje mala velka pismena.
            I s cestinou, tedy poradi AÁBCČ..aábcč…..
            V pripade nerozlisovani malych pismen treba AaÁáBbCcČč…
            V c# sem nenasel ze by to umelo samo, tak sem si to napsal.
            Pak to pustte na tak milion 30 znakovych retezcu.

            V php je na to asi funkce, ale nevim jak si poradi s cestinou jestli ignoruje pocatecni nuly nebo ne, v XSLT nevim.
            Nicmene pokud v XSLT je, tak na vygoogleni je PHP lepsi :)
            Jak je na tom xlst a trizeni se zadanim si vlastni funkce pro porovnani dvou elementu ?

            zdravi, Pavel

              1. Pavel

                Re: moje zkušenost

                Nejpoužívanější XSLT 2.0 procesor lze celkem snadno konfigurovat

                Pekne ale nestandartni, nebude fungovat vsude.

                Řadit lze podle jakéhokoliv výrazu, tedy i podle uživatelsky definované funkce

                To uz je lepsi.

                Dal jsem si praci a napsal testovaci xml transformaci v c#.
                Vstup je nasledujici (tecka pred p je aby to nesezralo html):

                <points>
                <.p x=„-63.5“ y=„-63.5“ z=„-63.5“ />
                <.p x=„-63“ y=„-63.5“ z=„-63.5“ />
                <.p x=„-62.5“ y=„-63.5“ z=„-63.5“ />

                <.p x=„62.5“ y=„64“ z=„64“ />
                <.p x=„63“ y=„64“ z=„64“ />
                <.p x=„63.5“ y=„64“ z=„64“ />
                <.p x=„64“ y=„64“ z=„64“ />
                </points>

                x,y a z jdou postupne po 0.5 od –63.5 do 64, to dava dohromady 224 radku, celkem cca 512MB.
                Vystup je serazeny podle x2+y2+z2 tedy prvni je x=„0“ y=„0“ z=„0“.
                Neni jednoznacne dany ale o to nejde.

                Na http://popelka.misto.cz/xslt jsou zdrojaky, vsechno je v Program.cs. Zbytek je solution a projekt do visual studia express.Prvne to vygeneruje soubor in.xml, pak ho znovu nacte, setridi a zapise do out.xml. Zkompiluje se to csc z adresare .net, jestli to pujde v mono netusim.
                V souboru in.7z je zazipovany vstup.
                V adresari bin je exe (na vlastni nebezpeci).

                Mam Athlon MP (Barton) 2GHz a 1GB pameti, a trva to nekolik minut, procesor jede naplno a proces ma 750MB.

                Nasleduje vystup (prvni cas je po spusteni, druhy po vygenerovani, treti pred trizenim, ctvrty po trizeni, paty po zapsani).

                11/12/2009 20:39:49
                11/12/2009 20:41:09
                sort0 11/12/2009 20:43:14
                sort1 11/12/2009 20:44:23
                11/12/2009 20:46:05

                1. Jiří KosekAutor příspěvku

                  Re: moje zkušenost

                  Implementovat seřazení v XSLT je o dost jednodušší než ve vašem C#:

                  <xsl:stylesheet xmlns:xsl=„ht­tp://www.w3.or­g/1999/XSL/Tran­sform“ version=„2.0“>

                  <xsl:template match=„/“>
                  <points>
                  <xsl:for-each select=„/points/p“>
                  <xsl:sort select=„abs(@x*@x + @y*@y + @z*@z)“/>
                  <xsl:copy-of select=„.“/>
                  </xsl:for-each>
                  </points>
                  </xsl:template>

                  </xsl:stylesheet>

                  Rychlost byla na mém počítači tak 3–4× pomalejší než kód v C#, což mi nepřijde tak hrozné. V diskusi jsem se neoháněl rychlostí XSLT, ale přehledností a snadností zápisu transformací XML.

                  Testy jsem dělal jen na 221 bodech, aby se mi to vešlo do paměti.

                  Jinak pokud by vám šlo o rychlost, tak byste měl rovnou při načítání XMLReaderem jednotlivé načítané body zatřiďovat do seřazené posloupnosti.

                  1. Pavel

                    Re: moje zkušenost

                    Zajimave, takhle napsany to vypada mnohem lip, to s cim sem se potkal bylo, mnohem horsi.

                    Jaky je pomer pouzite pameti procesu v c# a v XSLT ?
                    (v c# se jeste neco da usetrit pouzitim float misto double)

                    Jak ten XSLT procesor vyuziva CPU, jede naplno? na vice jadrech ?

                    Zkousel jsem tu transformaci pouzit v c# a ten umi zrejme jen XSLT 1.0
                    (XPathDocument a XslCompiledTran­sform).
                    Bez funkce abs to projde.
                    Je to dohromady asi 2.5× pomalejsi (cteni a zapis jsou stejne rychle, zpracovani je 6× pomalejsi)
                    Ma to 5× vetsi spicku pameti (663MB x 116MB), pri 221 bodech.
                    A na mem dvoujadrovem pracovnim notebooku (core 2 duo 2.2GHz) je to ciste 2× pomalejsi,ale 2 jadra se nepouziji a pamet to zere stejne.
                    Rekl bych ze pamet bude v tomto pripade asi vetsi problem nez cpu.
                    A ve vystupu nejsou konce radku :)

                    Kdyz sem s tim tenktat potkal,tak byla pamet taky problem.
                    Kdyz v tom xml byly i trendy (prubeh treba teploty v case), tak mel velikost tak 100MB. Z tech dat se pres xslt/javascript delaly vml grafy.Klienti mely 512MB pameti, coz na vsechno ostatni v pohode stacilo.To xslt se tusim nejak chroupalo pres internet explorer a bylo to na CPU a pamet dost rozezrany.

                    Jinak pokud by vám šlo o rychlost, tak byste měl rovnou při načítání XMLReaderem jednotlivé načítané body zatřiďovat do seřazené posloupnosti.
                    To si nemyslim, udrzovat setrizeny rostouci strom/seznam je slozitejsi nez ho jednorazove seradit.

                    PS: ten abs je zbytecny, sem to zmotal, chtel jsem to radit podle vzdalenosti od stredu,tak by tam melo by sqrt, ale pro samotne trideni tam nemusi byt vubec nic.

                    1. Jiří KosekAutor příspěvku

                      Re: moje zkušenost

                      Jaky je pomer pouzite pameti procesu v c# a v XSLT ?
                      (v c# se jeste neco da usetrit pouzitim float misto double)

                      Záleží na použitém procesoru XSLT. Ale vaše aplikace používá pro ukládání dat vlastní strukturu, nedrží celé vstupní XML, takže na tom musí být lépe. Navíc, pokud k domentu nemáte schéma, bude XSLT pracovat se všemi hodnotami jako s řetězci a přetypování na číslo provede pouze v okamžiku provádění nějaké matematické operace.

                      Jak ten XSLT procesor vyuziva CPU, jede naplno? na vice jadrech ?

                      Zálěží na konkréním procesoru. Já jsem používaj Saxon (Javu a .NET verzi). Při parsování vstupního XML procesor naplno nejel, pak už ano. Saxon využívá jen jeden procesor.

                      Ma to 5× vetsi spicku pameti (663MB x 116MB), pri 221 bodech.

                      Saxon.NET sežere jen 500MB, takže je úspornější než XSLT procesor z .NETu.

                      A ve vystupu nejsou konce radku :)

                      To něčemu vadí. Pokud vám to vadí, stačí použít <xsl:output indent=„yes“/>, nebo ty konce vkládat ručně.

                      Jinak pokud by vám šlo o rychlost, tak byste měl rovnou při načítání XMLReaderem jednotlivé načítané body zatřiďovat do seřazené posloupnosti.
                      To si nemyslim, udrzovat setrizeny rostouci strom/seznam je slozitejsi nez ho jednorazove seradit.

                      Je to složitější na naprogramování a teoretická časová složitost bude stejná. Ale při čtení a parsování XML je velice pravděpodobné, že procesor nejede naplno, protože ho blokuje pomalé I/O. Pokud by se v tomto čase začala data řadit, bude celkový čas běhu programu kratší.

                      Jinak, jestli vám XSLT kód přijde dlouhý, jde to napsat i v XQuery:

                      <points>
                      {
                      for $p in doc(‚in.xml‘)/po­ints/p
                      order by abs($p/@x*$p/@x + $p/@y*$p/@y + $p/@z*$p/@z)
                      return $p
                      }
                      </points>

                      1. Pavel

                        Re: moje zkušenost

                        Navíc, pokud k domentu nemáte schéma, bude XSLT pracovat se všemi hodnotami jako s řetězci a přetypování na číslo provede pouze v okamžiku provádění nějaké matematické operace
                        Muzete zkusit to schema pridat a zkusit zmerit rychlost a pamet ?

                        Jinak, jestli vám XSLT kód přijde dlouhý, jde to napsat i v XQuery
                        To vypada jeste lepe, muzete opet zkusit zmerit rychlost a pamet ?

          2. Pavel

            Re: moje zkušenost

            Pak me napada jeste jedna zvrhla uloha.
            Ve vstupnim xml budou elementy
             – se souradnicemi bodu
            <point x=„0.11“ y=„0.12“ z=„2.34“ />
             – se seznamem polygonu jako posloupnost 3 a vice techto bodu + rgb barva
            <poly rgb=„#ff00ff“ p1=„1“ p2=„2“ p3=„3“ .. />
             – defince podledu ve 3D (bod, 3 vektory a viewport )
            vyleze z toho vykreslene SVG coz je tusim xml,kde bude vstupni 3d mesh vykreslena z tohoto pohledu.
            Predpokladejme ze polygony neni nutne „rezat“, jsou dostatecne male takze staci jim jen prepocitat souradnice a spravne je seradit.
            A budete z toho mit peknou 3d vizualizaci na grafy atp. :)

            zdravi, Pavel

            PS: pokud je to pro jazyk budoucnosti moc snadne, muzete si zkusit ze dvou takovych mesh objektu udelat union (mesh povrchu jejich sjednoceni). Tam uz se bez rozkladani polygonu neobejdete.

            1. Jiří KosekAutor příspěvku

              Re: moje zkušenost

              pokud je to pro jazyk budoucnosti moc snadne

              Asi vás popudil titulek, ale je to jeden ze série článků a XML API v PHP, který ukazuje, jak jde v PHP spouštět transformace zapsané v XSLT.

              Jinak k vaší úloze – jestli chcete, abych to napsal, potřebuji konkrétní zadání, tohle nemá přesný vstup, výstup a popis toho, co přesně se má stát, takže různé implementace nepůjde porovnat. A navíc, proč generovat SVG, když můžu vygenerovat X3D a to se o vše postará samo ;-)

              1. Pavel

                Re: moje zkušenost

                Jazyk budoucnosti me skutecne popudil v minulosti :)

                jestli chcete, abych to napsal
                Neni nutne aby jste to napsal,stejne by se to nedalo asi rozume k necem pouzit, bez napsani hromady veci okolo.

                A navíc, proč generovat SVG, když můžu vygenerovat X3D a to se o vše postará samo
                Otevrete X3D ve firefoxu bez toho,abyste neco stahoval ?

                Ale mam dalsi orisek. Rekneme ze mam 100MB xml a nakonec budu chtit pridat nejaky element. V c# si otevrete soubor, seeknete se o kousek zpatky a prepisete konec. Co na to XSLT ?

                1. Inkvizitor

                  Re: moje zkušenost

                  > Ale mam dalsi orisek. Rekneme ze mam 100MB xml a nakonec budu chtit pridat nejaky element. V c# si otevrete soubor, seeknete se o kousek zpatky a prepisete konec. Co na to XSLT ?

                  A co na to nadřízený vývojáře, který ukládá 100 MB dat do XML souboru? ;-)

                  1. Pavel

                    Re: moje zkušenost

                    A co na to nadřízený vývojáře, který ukládá 100 MB dat do XML souboru? ;-)

                    V realu no nebylo tak velky, a byl to vysledek logovani udalosti, a delilo se to co jeden den to jeden soubor.

                    Nadrizeny takove detaily neresi :)

                2. Jiří KosekAutor příspěvku

                  Re: moje zkušenost

                  Ono to seeknutí o kousek zpátky není zas tak jednoduché, pokud má fungovat ve všech případech.

                  V XSLT si uděláte v identickou transformaci, která na konec přidá nová data.

                  Ale ukládat 100 MB do XML uloženého v souboru, pokud to chcete často měnit, není moc dobrý nápad. Na takovéhle věci je lepší použít XML databázi.

                  1. Pavel

                    Re: moje zkušenost

                    Ono to seeknutí o kousek zpátky není zas tak jednoduché, pokud má fungovat ve všech případech.
                    Ano, v tomple pripade tam byl vzdy stejny element a bylo to jasne.

                    Na takovéhle věci je lepší použít XML databázi
                    Kdyz mate xml soubor, tak do neho neco dotnetem zapisete a pak si ho proste zkopirujete.Tady slo o logovani, zadne slozite zpracovani.

                    Kdyz budete mit XML databazi tak ji pravdepodobne budete muset instalovat, nebo kopirovat. Kdyz z budete chtic neco dostat, bude to zas muset delat nejakym dalsim programem.Tim se to vsechno komplikuje.Po­citac,na kterem to pouzivate je treba minimalne zatizit instalacemi.Navic instalace sw v nasi firme podle jakychsi smernic maji psat do jakychsi dokumentu, coz me vubec nelaka.

                    1. abrakadabra

                      Re: moje zkušenost

                      Co sa tyka logovania, ja som to riesil tiez zapisom do xml. Ale ked mal log cez 30 mega na den, zacal som sekat po 6 hodinovych cykloch, podla smien vo vyrobni :-)

                      Ale rad by som polozil otazku. Mam vstupne xml. Su tam zaznamy napriklad o cestach nejakeho vozidla. Su tam zaznamy za mesiac a dajme tomu prve dva kalendarne tyzdne to jazdilo 5 ciest kazdy den a potom tyzden nic a potom opat tyzden kazdy den nejake cesty.

                      Da sa spravit v xslt to, ze medzi tie cesty sa doplnia 4 elementy, ktore budu predstavovat sumy najazdenych kilometrov pre jednotlive tyzdne? A samozrejme potom od toho budem chciet este jeden element o celkovej sume nakoniec.

                      Otazka asi znie, ci sa da pouzivat kalendar a grupovat podla neho nieco. Toto konkretne mam nakodene v jave i ked som dost zvazoval xslt, len ako vzdy, nebol cas sa ucit to najidealnejsie riesenie. V jave bol i s tym grupovanim po tyzdnoch mini problem vzhladom na to, ze kalendar povazuje nedelu za prvy den tyzdna, ako nejaky anglican keby to kodil :D

                      Dakujem za odpoved. Zvazujem, ze si len vramci skilovania prekodim danu ulohu do xslt.

                      1. Jiří KosekAutor příspěvku

                        Re: moje zkušenost

                        Otazka asi znie, ci sa da pouzivat kalendar a grupovat podla neho nieco. Toto konkretne mam nakodene v jave i ked som dost zvazoval xslt, len ako vzdy, nebol cas sa ucit to najidealnejsie riesenie. V jave bol i s tym grupovanim po tyzdnoch mini problem vzhladom na to, ze kalendar povazuje nedelu za prvy den tyzdna, ako nejaky anglican keby to kodil :D

                        V XSLT 2.0 můžete grupovat podle libovolné hodnoty. XPath sice nemá funkci vracející týden, ale k číslu týdne se lze dostat pomocí funkce format-date() a formátovacího řetězce „W“. Pokud mají být jednolivé týdny seskupeny, stačí seskupovat podle tohoto výrazu. Funkci format-date() lze určit locale, takže začátek týdne to bude brát dle vašich preferencí.

  10. Jakub Vrána

    Hlavní problém

    Ve webových aplikacích je často potřeba nějaký XML dokument načíst, data uložit do databáze a pak zase vrátit obvykle v HTML. Do databáze se musí ukládat strukturovaná data, protože je nad nimi potřeba vyhledávat a třídit. To by šlo asi udělat i v XSLT, ale dokud se pro ukládání dat používají relační databáze a ne nativní XML, tak je XSLT pro tento scénář prakticky nepoužitelné (kvůli rychlosti).

    XML databáze nijak zvlášť rozšířené nejsou, ale i tak by mě zajímalo, jak by se takovýto scénář realizoval. Jestli třeba každý importovaný produkt má svůj vlastní „záznam“ nebo jestli je vše v jednom velkém XML, jestli jsou data nějak strukturovaná do tabulek jako v relačních databázích nebo jestli jsou třeba parametry smíchané s ostatními informacemi o produktu, jak se do toho přidávají další položky a tak.

    1. Jiří KosekAutor příspěvku

      Re: Hlavní problém

      Asi nemá cenu psát do komentáře článek o tom, jak fungují nativní XML databáze.

      Jestli tě hodně zajímá, jak jde čistě na XML technologiích udělat webovou aplikaci, zadej si do Google XRX.

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=3116