Re: [xsl] [XSL] XSL Browser Integration

Subject: Re: [xsl] [XSL] XSL Browser Integration
From: Abel Braaksma <>
Date: Mon, 17 Sep 2007 20:35:52 +0200
Scott Trenda wrote:
In the above case, if you view the source from the browser, you'll see
the raw, unprotected data, since your source is the XML document itself.
In many business cases, there are several parameters and values that
have nothing to do with the presentation of the data, but are crucial to
organizing that data, and should not be available for the user to see
for one reason or another. In your XSLT, you may be discarding these
along the way to presentation, but if you do this on the client side,
you're still including it in the data, and so it'll still be visible to
anyone viewing the site - including, at the absolute worst-case
scenario, Google bots, at which point it's public forever.

I don't think it is likely that many people use client side transformation like you suggest here (on a side note, I know one site that presents their pages as somepath-to-page.xml, you reckon this should be XML post-processed on the client, but no, it is not even correct xml, it is just badly constructed html: If you do not use the (X)HTML tags in your pages, search bots won't easily find you or you have to put in quite some effort for them to do find you. Furthermore, I totally agree with your standpoint that it is not so handy to show the bare data to the user. Which is why this is a far from typical use.

Several uses on client side, however, are very worthwhile:

1. Post rendering basic XHTML
2. Transforming data for respresentation on the client side through XHR
3. Transforming representation data for processing on the server side as XML, through XHR
4. Pre- / post- processing and building command XML, where your server "talks" with XML commands
5. Validation
6. XUL / XAML like processing (widgets etc)

Of course, 2 and 3 do not necessarily need to be XHR, but it is by far the most versatile way to communicate under the surface with the server. Nr 4 is the one I mostly see because of lightweight command services that build up client side RIA applications. For instance, in a Excel-like grid, when a user changes a cell, the data entered is validated on the client, than send to the server after being processed with XSLT into an XML object.

As it turns out, it is very tedious to build XML objects using pure DOM. It is very handy to just use an XSLT processor with a couple of parameters (which can of course be DOM objects themselves) and build the XML command entirely using XSLT.

In the case of 5: this is often done with a couple of javascript objects. But why not load a Schematron file and test it with XSLT against any input data? (the input probably being put into some format that can be send to the server).

Nr 6 is something very useful, I think. There is a specification coming up for widgets, but it will take quite some time before that is finalized. I use my own widget format, and probably many with me, to build my own RIA application by just putting together the building blocks. Again, both the putting together and the processing from widget-xml to XHTML is done in XSLT.

This is what I meant when I said "presentational purposes only". If all
that's left to do is take the data that will be displayed on-screen (and
only that data) and make it into a structured, styled HTML document,
then by all means, let the browser take over from there. Until then,
XSLT still has great power server-side in being able to take the raw
data and arrange it in a more meaningful form with respect to the final
result document.

Some of the examples above are not about presentational purposes. However, I think they have a well-deserved place on the client side when correctly balanced against possible resources and roles (you don't want the client to do the hardcore xslt processing that indeed *should* take place on the server). When balanced correctly, the overall performance of both client *and* server increases dramatically.

Also, the forms/parameters argument still holds - you can't POST/GET to an XML document and expect it to have an effect on the transformation, nor can you store anything on your server. Even a very light preprocessor scan will still be very useful here, but only on the server side.

I don't think I understand you here. Of course, persistence is on the server. But in the Excel-like example above, any changes are send through a POST with a body of XML, expecting XML in return. The data is then stored on the server.

And when I do a POST/GET using XHR, I get XML back and I almost *have to* use XSLT to make it more accustomed to client side scripting, processing or presentation.

-- Abel Braaksma

Current Thread