Na tom neco je. Takova C-commitee musi pro kazdy svuj novy "standard" vypracovat referencni implementaci. Kdyby to delalo W3C, to by bylo na svete hned lip ....
W3C vymýšlí standardy, u kterých jí vůbec většinou nezajímá praxe. V poslední době mě napadlo, že se chová jako teoretik odtržený od života.
Mě už bylo kdysi divné, když vymýšleli HTML, že v podstatě doháněli okolí. Je mi divné, když XHTML verze 2 není zpětně kompatibilní s verzí 1. Říkal jsem si, no co, alespoň se bude používat čisté XML, a bude fajn. A teď vidím, že W3C pracuje na tom, aby zničili i XML.
Pak se vůbec diví, že lidi na to dlabou a na čistotu podle norem nehledí.
Považoval bych od W3C za slušné, aby ke každému standardu byl povinně dodán balík knihoven pro základní platformy pro práci s jejich standardy. Ke všemu by musela existovat referenční implmentace, která by byla použitelná v praxi. Jinak by normu W3C nebylo možné vůbec uveřejnit.
K čemu vlastně je, že W3C překračuje plán, když se snaží, aby jejich standardy bylo co nejhůře implementovatelné?
Nevidim to docela tak negativne. Ten nasledujici krok k XSLT/XPATH/2.0 ma dost zasadni opodstatneni.
Kdo pracuje vice s XSLT1.0/1.1 a XPahtem vi, o cem mluvim, kdyz reknu, ze je to dobry zacatek, ale potrebuje to byt o neco silnejsi.
Treba hloupy problem - tranformuj prispevky, ktere jsou starsi nez 7 dnu do jineho vystupu... Zkusili jste tuhle banalni vec udelat nekdy pomoci XSLT? (za predpokladu, ze to datum je samozrejme v human-readable formatu...) Jde to, ale je to strasne, strasne kostrbate a podporovat lokalni formaty? ...
To se zmeni, ty typy vpodstate neni vubec napad k zahozeni. Moc by se mi libilo neco jako match="*[@date < '12.1.2003']" apod.
Problem mozna je, ze toho je na verzi 2.0 az moc. Neni to problem ani tak z podstaty, jako z programatorske linosti... (Na druhou stranu parsovani pomoci regularu v XSLT? To musite prece jasat... ne? ;-)
Sam posledni dobou pouzivam XSLT1.0/1.1 a na 2.0 cekam jako na smilovani - aspon doufam, ze vyresi problemy, ktere jsem cetl, ze by to vyresit melo. Ale doufam, ze ackoliv chtej vsude cpat schemata, ze to cloveku spokojenemu s DTD nebude hazet moc klacku pod nohy.
Podle toho smeru, kterym se to ubira, se bez toho za chvili neobejdes... Vice nez DTD znam XML Schema a musim rici, ze idea za XML Schema je vpodstate vyborna (pominu-li nektere, pro mne nepochopitelne nedostatky a prozatim naprosto neakceptovatelny fakt, ze se nektere dnesni validatory proste nejsou schopny shodnout, je-li dany dokument validni ci neni... Podpora XML Schema je prozatim dost uboha, coz je vazny problem. Ale to se urcite brzy zmeni... doufam ;-) Taky zpusob definice XML Schema ktery je inspirovany objekty. Moc pekne.
Nyni pouzivam XML Schema nejen jako validaci, ale i jako dokumentaci k XML souborum.
Je to proste super (Sam se divim, jak rychle dokazu zapomenout na ty hodiny nadavani a nekonecne hledani reseni jak to udelat v XML Schema... :-)
Presne o tom to je. Naco nam je sebalepsi standard ak neexistuje 100% implementacia. Lenze sucasna situacia je ze standardy su implementovane tak na cca 70%
XSLT se dnes pouziva mnohem vic, nez byl puvodni zamer. Proto v nekterych ohledech nestaci. Kdyby doslo k doplneni potrebnych funkci (jak se o to snazilo XSLT 1.1, resp. EXSLT), jasali by asi vsichni. Kdyby bylo mozne pouzivat typy jako rozsireni, tezko by si nekdo stezoval. Problemem "z podstaty" je, ze XSLT 2.0 uz neni univerzalnim transformacnim jazykem pro well-formed dokumenty, coz je skoda pro XML i XSLT.
Jeste poznamka: XPath/XSLT 2.0 jsou rozhodne implementovatelne standardy, byt obtizneji nez v1.0, ale to uz tak chodi. Referencni implementace take existuje (Saxon 7.x); pise ji autor specifikace (Michael Kay) soubezne se specifikaci samotnou. V tomoto ohledu si neni nac stezovat.
Jako nekdo, kdo se pokousel vymyslet, jak by mela vypadat implementace pouheho xpath-1.0, musim rict, ze to sice jde, ale efektivita jde do haje. xpath-2.0 jde jeste dal. Obcas mi prijde ze zvysuji silu jazyka jenom pro tu silu -- realne pouzitelne to ve vysledku tezko bude. Stejne se bude pouzivat jenom zaklad nebo se bude spolehat na to, ze data jsou opravdu mala...
Pripada mi to, jako kdyby nekdo chtel po SQL databazi s pulmilonem tabulek o dvou radcich (pokud mozno s neznamym poctem sloupcu a typech v nich), aby fungovala soucasne taky efektivne...
