Názory k článku XML - máte co jste chtěli

Pěkný článek.
Zajímalo by mne, proč není u článků (bootN.xml) a stylů (boot.xsl, summary.xsl) hlavička XML (<?xml version=...) a dokonce ani u souboru summary.xml, který je generován! Nevadí to XSLT procesoru, případně SAXu?

Ještě poznámka: u celkového výstupu (summary.xhtml) se používají styly pro název článku a autora (<h2 class="nazev">, <h3 class="autor">), které nejsou nikde definovány - předpokládá se pravděpodobně definice CSS stylu, který může být eliminován definicí konkrétního stylu zobrazení již v souboru summary.xsl.

Pravda <?xml ...> tam neni. Pri zpracovani to nicemu nevadi (alespon u me ne), ale je to formalni chyba. V pripade, ze by existovalo xml verze 2 uz by to byl problem. Stejne tak by to bylo treba pokud by XML dokumenty nebyly v UTF ale v jinem kodovani.
Jde tedy o chybu autora (tedy me), ktera je navic velmi "nepedagogicka" :). Sorry.
Pokud jde o ty "class"y, napsal jsem je tam nejak ze zvyku a pak se o tom zapomel zminit. V rozsahlejsim HTML je lepsi si jednotlive elementy "oznacit" timto zpusobem, aby pak mohl clovek lepe pracovat se zobrazenim pomoci CSS. Kdyz to clovek nakonec nevyuzije tak to nevadi.

BEDA

Zajimalo by mne zda jde prevod z XML treba do XHTML pomoci XSLT nejak automatizovat na serveru. Jde mi o toto. Mel bych napriklad redakcni system a autori by uploadovaly XML dokumenty na server treba do DB. Mohu je nejak pomoci PHP a samozrejme XSLT prevest? (nechci si psat v PHP vlastni XSLT procesor:)
Diky za odpoved
Petulka

Ano, je to mozne, staci prikompilovat do PHPcka podporu Sablotronu. Modul do PHPcka pro podporu Sablotronu je primo soucast zdrojaku PHPcka a vlastni Sablotron lze stahnout z http://www.gingerall.com Modul je sice oznacen jako experimentalni, nicmene je docela dobre pouzitelnej.

Jediný problém je v tom, že Sablotron nepodporuje celou specifikaci XSLT. Na jednoduché věci je to dobré, ale složitější konstrukce nezvládne. Když jsem si s ním naposledy hrál, by navíc pro delší dokumenty dost pomalý (pomalejší než javové implementace, když jsem si odmyslel dobu potřebnou na start JVM).

V některé z dalších verzích PHP má být obecné rozhraní pro XSLT, a půjde použít několik procesorů - minimálně Sablotron a Xalan-C.

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.

BEDA

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

Všechny současné XSLT procesory načítají celý XML dokument do paměti a používají k tomu buď přímo DOM reprezentaci nebo něco hodně podobného.

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