Hledam vhodny a perspektivni XSLT procesor pro praci nad XML a hlavne pro DocBook. Zatim mam pocit, z toho co jsem videl a zkousel ze XML a XSL, XSLT ... jsou pekne veci o nichz vsichni mluvi, ale nikdo je nevidel (tedy ja je nevidel fungovat).
Rozumejte, kdyz chci vyzkouset C, Pascal, Pearl, Python, ... Tak jej proste pouziji a podle prirucky (helpu, literatury, ...) zkusim to ci ono a neco se naucim. Kdyz chci zkusit XML, tak proste nejsem schopen zprovoznit to prostredi. XT tusim nejel vubec, SAXON mne poslal do CENSORED s iso-8859-2, javovsky xalan mel asi taky problem (uz si nevzpomenu, musel bych odkomentovat prislusne radky v mem skriptu a nainstalovat javovsky Xalan. Zatim mam pocit ze veci kolem XML jsou takove nejake nodovarene, DODO (dodelej doma).
Ted bych se zeptal neco konkretniho, zkompiloval jsem si Xalan verzi 1.0-3 (ta -3 je od Debianu) a nahradil ve svem skriptu volani saxonu xalanem. A vysledek, nefunguje. Z chybove hlasky nejsem moc chytry. Po specifikaci radku s chybou XSLT/NamespaceHandler.cpp:125: bla bla, konci "Assertion 'length(theURI) > 0' failed.
Jak je na tom novejsi verze Xalanu? Zvlada DocBook?
Tak se mi zatim nepodarilo overit jestli Xalan zvlada encoding="iso-8859-2". Pro saxon musim vse pred pouzitim konvertovat do UTF. A navic je saxon pod javou z meho pohledu nechutne pomaly.
S DocBookem nemam bohuzel zadne zkusenosti. Pokud jde ale o obecne XSLT transformace tak jsem celkem nemel problemy s zadnym zminovanym procesorem. Saxon i XT jsou (na javu) relativne rychle, Xalan-J mi prijde "nejspolehlivejsi", ale neni zrovna rychlik. Xalan-J take podporuje iso-8859-2 (u ostatnich nevim jaka je aktualni situace), protoze konverze je soucasti standardni Javy.
Jak jsem psal zdaleka nejrychlejsi je Xalan-C (alespon z toho co jsem zkousel), ale je treba mu predlozit dokument v UTF-8.
Pokud jde jeste o Xalan-C tak pouzivam verzi 1.1, ktera je k disposici na xml.apache.org a zadne DODO jsem pouzivat nemusel.
Pokud jde o problemy s kodovanim, napada me jen zda pouzivate ve svych XML dokumentech <? xml version="1.0" encoding="iso-8859-2" ?>. Jestli ano a Vas dokument je skutecne v iso-8859-2 pak nevidim duvod proc by to Xalan-J nemel zvladnout.
Problem je v tom, ze casu mam malo, a problemu co potrebuji vyresit mnoho. Nevim jestli mi stoji za to zkouset Xalan v1.1, protoze z meho pohleduj e Xalan v1.1 DODO. t.j. musim si sam vytvorit binarni balicek(presneji balicky) a ten nainstalovat. Mozna to zkusim. Jestli zvlada iso-8859-2 tak to je plus, jak jsem psal Saxonu to musim predzvykat.
Prubirsky kamenem je DocBook, pokud XSLT neprezvyka DocBook, tak je pro mne nepouzitelny k publikaci dokumentu. Nicmene jeste je tu problem transformaci a tam by se snad uplatnil, zejma kvuli rychlosti. Ikdyz nevim, nepouziva Xalan DOM? A nevyzaduje DOM mit cely rozparsovany dokument v pameti? Ted si nejsem jisty. No zatim to mam udelane tak za mam skript xslt, ktery vola nejaky xslt procesor, ted konkretne saxon. Takze jsem trochu pripraven na vymenu tohoto procesoru za jiny :).
XML parsery nemusí podporovat jiná kódování než UTF-8 a UTF-16.
Jinak s DocBookem bez problémů funguje XT, Xalan i Saxon. Pro plné využití existujících stylů je nejlepší použít Xalan 2 nebo Saxon. Nejrychlejší je XT, Saxon ještě ujde, Xalan (Java) je dost pomalý.
U všech XSLT procesor lze změnit použitý parser a použít nějaký, který umí i česká kódování. Upravené XT s podporou českých kódování je na adrese http://www.kosek.cz/xml/xt/. Postup, jak použít Saxon s jiným parserem je na http://www.kosek.cz/xml/saxon/. Pokud máte i styl v českém kódování, přidejte Saxonu i parametr -y se stejnou hodnotou jakou má -x (stránka je o něčem jiném než o českém kódování, proto tam tohle není zmíněno).
