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.
Seriál: Přehled podpory XML v PHP5 (6 dílů)
- Přehled podpory XML v PHP5 5. 10. 2009
- PHP a XML: SAX – čteme pěkně popořádku 12. 10. 2009
- XMLReader – když se zamotáme do SAX 19. 10. 2009
- DOM – načteme to do paměti 26. 10. 2009
- XPath – rychle to najdeme 2. 11. 2009
- XSLT – jazyk budoucnosti 9. 11. 2009
Nálepky:
XSLT lze použít i pro naší úlohu, protože potřebujeme převést RSS (což je jen specifický případ dokumentu XML) do formátu HTML.
Příklad 7. XSLT styl pro převod RSS do HTML – rss2html.xsl
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="html" encoding="utf-8"
doctype-public="-//W3C//DTD HTML 4.01//EN"/>
<xsl:template match="channel">
<html lang="cs">
<head>
<title>Přehled zpráv</title>
</head>
<body>
<h1>Přehled aktuálních zpráv ze serveru
<a href="{link}"><xsl:value-of select="title"/></a></h1>
<dl>
<xsl:for-each select="item">
<dt><a href="{link}"><xsl:value-of select="title"/></a></dt>
<dd><xsl:value-of select="description"/></dd>
</xsl:for-each>
</dl>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
XSLT pro svůj zápis používá syntaxi XML, proto musí začínat deklarací XML. Výkonné instrukce XSLT patří do jmenného prostoru http://www.w3.org/1999/XSL/Transform, pro který se obvykle používá prefix xsl. Celý styl se zapisuje dovnitř elementu xsl:stylesheet. Uvnitř stylu lze používat další instrukce. My například pomocí instrukce xsl:output nastavujeme parametry výstupu – v jakém bude kódování, jaký se použije formát (HTML/XML) a jak bude vypadat deklarace typu dokumentu:
<xsl:output method="html" encoding="utf-8"
doctype-public="-//W3C//DTD HTML 4.01//EN"/>
Nejdůležitější částí každého stylu jsou šablony ( xsl:template). Každá šablona definuje, jak se bude zpracovávat určitá část vstupního dokumentu (nejčastěji nějaký konkrétní element). Náš styl obsahuje jen jednu šablonu, která definuje způsob zpracování elementu channel:
<xsl:template match="channel"> … </xsl:template>
Šablona se pak chová tak, že v ní obsažené texty a elementy nepatřící do jmenného prostoru XSLT kopíruje na svůj výstup. Elementy patřící do jmenného prostoru XSLT jsou chápány jako instrukce, které XSLT procesor provádí. V naší šabloně jsou použity jen dvě instrukce xsl:value-of a xsl:for-each.
Instrukce xsl:value-of slouží k vypsání výsledku XPath výrazu do výstupu. Takže například instrukce:
<xsl:value-of select="title"/>
vypíše obsah elementu title, který je dítětem aktuálního uzlu. No a uvnitř šablony je aktuální ten uzel, který šablona právě obsluhuje, tedy element channel.
Instrukce xsl:for-each je naopak příkaz cyklu. Pro všechny uzly, které vybere XPath výraz uvedený v atributu select, se provede kód uvedený uvnitř této instrukce. Uvnitř cyklu se navíc aktuálním uzlem stává uzel, pro který se právě provádí tělo cyklu, takže XPath výraz title nyní vybírá název položky, ne kanálu v RSS dokumentu.
Potřebujeme-li nějakou hodnotu vložit do atributu, nemůžeme použít instrukci xsl:value-of, protože syntaxe XML neumožňuje používat elementy uvnitř hodnot atributů a XSLT musí této syntaxi vyhovět. Uvnitř atributů proto můžeme výrazy jazyka XPath zapisovat do složených závorek ( {…}).
Aby bylo naše řešení kompletní, musíme samozřejmě umět na dokument XML aplikovat transformaci popsanou pomocí XSLT a její výsledek poslat do prohlížeče. V PHP je tento úkol velmi jednoduchý, protože obsahuje i knihovnu pro práci s XSLT. Stačí dokument i styl načíst jako DOM objekty do paměti, poté si vytvořit nový procesor XSLT (třída XSLTProcessor), načíst do něj styl z DOM stromu a spustit transformaci.
Příklad 8. Transformace dokumentu XML – xslt.php
<?php
// načtení dokumentu XML
$xml = new DomDocument();
$xml->load("../data/luparss.xml");
// načtení stylu XSLT
$xsl = new DomDocument();
$xsl->load("rss2html.xsl");
// vytvoření procesoru XSLT
$proc = new xsltprocessor();
$proc->importStylesheet($xsl);
// provedení transformace a vypsání výsledku
echo $proc->transformToXML($xml);
?>
Viděli jsme, že PHP nabízí několik různých metod pro čtení dokumentů XML. Pro zpracování rozsáhlých dokumentů (větších než jednotky megabajtů) jsou vhodná jen rozhraní SAX a XMLReader. Tato rozhraní jsou navíc velmi rychlá.
Můžeme-li si dovolit načíst celý dokument XML do paměti, máme na výběr mezi rozhraními SimpleXML a DOM. Pro dokumenty s jednoduchou strukturou je použití SimpleXML většinou jednodušší než použití DOMu. Nicméně DOM rozhraní na rozdíl od SimpleXML umožňuje přístup ke všem informacím uloženým v dokumentu XML. Navíc rozhraní DOM umožňuje dokument XML v paměti i modifikovat.
Máme-li již však dokument načtený celý do paměti pomocí DOM, je v mnoha případech vhodnější využít nějaký nástroj vyšší úrovně, jako je XPath nebo XSLT. Přístup k datům uloženým v XML a jejich zpracování je mnohem efektivnější než při použití nízkoúrovňových metod DOM.
Více informací o knize naleznete na stránkách nadavatelství Grada a na stránkách autora.
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.
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'); } ...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 doporuč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.).
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.
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
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/standardizoval 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
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 jazyka
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á.
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 ;-)
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.
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.
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.
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. ;-)
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?
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í
Ř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.
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í.
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.
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.
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.
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“}.
$xml->children(‚dc‘, TRUE)->title
Aha, nebo správnější $xml->children(‚http://purl.org/dc/elements/1.1/‘, false). Druhý parametr přibyl v PHP 5.2.0.
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
>>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.
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
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,uzivatelske 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
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,uzivatelske 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á ;-)
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
<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.
OK. Nechame pracovat cas, uvidime kolik lidi u toho zustane a kolik od toho utece :)
zdravi, Pavel
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
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.
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 ?
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í.
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.
presli jsme na freemarker, dela se v nem mnohem jednoduseji
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“.
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?
musim nakonec souhlasit s nazorem ktery jsem sam povazoval za trapny, ale xml dnes opravdu uz neni moderni, naopak je to spis cosi prehistorickeho
Např. formátování podle prislovi1.xml se dá udělat zhruba takto: http://paste.org/…n/view/11671
Více o práci s XML v jazyce Scala lze najít zde:
http://burak.emir.googlepages.com/…k.docbk.html
Scala spojuje výhody OOP a FP, má dobrou typovou inferenci a zajímavé jsou XML literály, které jsem ukázal v příkladu. Podle mě stojí za zvážení.
Jde to v tomto případě i jednodušeji: http://paste.org/…n/view/11672
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 ;-)
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.
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.
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ší ;-)
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 ;).
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 ;-)
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
Nejpoužívanější XSLT 2.0 procesor lze celkem snadno konfigurovat a vše co píšete umí:
http://www.saxonica.com/…llation.html
Řadit lze podle jakéhokoliv výrazu, tedy i podle uživatelsky definované funkce.
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
Implementovat seřazení v XSLT je o dost jednodušší než ve vašem C#:
<xsl:stylesheet xmlns:xsl=„http://www.w3.org/1999/XSL/Transform“ 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.
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 XslCompiledTransform).
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.
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‘)/points/p
order by abs($p/@x*$p/@x + $p/@y*$p/@y + $p/@z*$p/@z)
return $p
}
</points>
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 ?
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.
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 ;-)
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 ?
> 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? ;-)
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 :)
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.
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.Pocitac,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.
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.
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í.
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.
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.