Lists Home |
Date Index |
Here is my take on a client side XSLT engine. There are couple things
a) checking the environment dependencies like for instance a particular
b) pipeline processing
c) non HTML output like for instance SVG (this last thing works in IE but
not in Firefox)
d) other stuff you guys have in mind.
The following link works in both IE 6.x and Firefox 188.8.131.52 may work with
other version but I didn't checked yet. The code will be open source and
freely available soon (I still need to decide on the licence)
Here is the link:
Actually, the xml document and the xslt have to be on the same domain. A
small php redirector would do the job to fool the browser platform to think
it's in the same domain.
Note: don't get fooled by the window.php thing. It has nothing to do with
PHP and the engine can be renamed as well window.web as lomg as your server
handle this MIME type. I was simply lazy to set the MIME type on my server
and reused an existing one. Any MIME type, file extension would work as long
as it is not .htm/.html and anything the browser platforms think could
What's happening behind the curtain of the previous link:
a) the URL is parsed on the client side just after window.xxx is loaded in
the browser platform.
b) parameters are extracted and passed to an interpreter handling different
function based on the parameters. For instance, it loads an XML document and
convert it into a DOM if the xml parameter is present. Idem for XSLT. In the
last case the "validate" parameter indicates to the engine to not validate
the parameter list. Some parameters like "xml", "xslt", "validate" are
reserved words. Other keywords than the reserved ones can be used as
parameter names. Here is an example where the default style is overloaded
with another one. Because the "css" keyword is not a reserved one it is
simply passed to the XSLT template for processing.
Here is the other link:
Now an alternative way to see the hierarchical collection with a widget
flatting it into a single layer drop box
The key thing here is to treat the browser as a platform like we would do
with other platforms like Java or .net. To get something more sophisticated
than just HTML interpretation, we need more sophisticated tools. Luckily,
the browser platforms are more versatile than most people think it is (with
the exception of the AJAX movement who treat the browser as a run-time
sandbox able to interpret declarative (HTML) and non imperative languages
functionalities and hence add new interpreters through the plug-in mechanism
- as an example, to load an SVG interpreter).
Now, what about including an RDF description to indicate to the engine the
required capabilities? If present the engine can check the requirements and
possibly offers a way to download what is missing or redirect to another
downgraded information context. What do you think? Any suggestion on the
content of the RDF description or any other suggestion?
Didier PH Martin