Discussion: Postponing XSL processing to browsers

[Christian Schlichtherle <ch...@schlichtherle.de>]

Hi everyone,
 
(this is a long mail to start a discussion about postponing XSL processing
to browsers - please skip if you don't mind)
 
Recent browsers (MSIE 7, Firefox 2 and may be many more) support XSL 1.0
stylesheets or better. So it should not be a new idea to split up an XML
processing pipeline in Cocoon in two parts:

1.	Create arbitrary XML data or document.
2.	Detect browser's XSL support. If not supported, transform the XML to
(X)HTML with a stylesheet as usual. If present however, just add a
processing instruction with a reference to the same stylesheet to the XML
data or document.

The advantages of this simple architecture are obvious:

*	The (X)HTML rendering can be delegated to the client.
*	The stylesheet may be a cacheable element which is used in all
server responses, so that the browser and the server only need to transfer
XML on subsequent requests.

This should make a web application much more scalable.
 
Implementing this as a Cocoon pipeline is straightforward: First there needs
to be a conservative selector which detects the broswer's XSL support. For
the first attempts, I use something like this:
 
    <map:components>
        <map:selectors default="xslbrowser">
            <map:selector logger="sitemap.selector.xslbrowser"
name="xslbrowser" src="org.apache.cocoon.selection.BrowserSelector">
                <browser name="xsl" useragent="MSIE 7"/> <!-- Internet
Explorer 7+ (no regex support here) -->
                <browser name="xsl" useragent="MSIE 8"/>
                <browser name="xsl" useragent="MSIE 9"/>
                <browser name="xsl" useragent="Gecko"/> <!-- Firefox and co.
-->
            </map:selector>
        </map:selectors>
    </map:components>

And the processing pipeline looks similar to this:
 
    <map:pipelines>
        <map:pipeline>
            <map:match pattern="*.html">
                <map:generate src="{1}.xml"/>
                <map:select type="xslbrowser">
                    <map:when test="xsl">
                        <!-- Smart browser: Add processing instruction for
XML stylesheet. -->
                        <map:call resource="add-xml-stylesheet">
                            <map:parameter name="href"
value="{request:contextPath}/resources/xml2xhtml.xsl"/>
                            <map:parameter name="type" value="text/xsl"/>
                        </map:call>
                    </map:when>
                    <map:otherwise>
                        <!-- Dumb browser: Perform XSLT on server. -->
                        <map:transform src="/resources/xml2xhtml.xsl"/>
                    </map:otherwise>
                </map:select>
                <map:serialize type="xml"/>
            </map:match>
        </map:pipeline>
    </map:pipelines>

After some initial tests with Firefox 2 and Internet Explorer 7, my results
are very, very promising: The integration is a transparent experience for
the user and speeds up the browsing noticeably. You can only tell the
difference by looking at the document source in the browser.
 
To add some smarts to the stylesheet while reqstricting it to be XSL 1.0,
I've added some more stuff to the processing pipeline so that the XSL
stylesheet gets preprocessed by JXTemplate based upon some query parameters.
Though not processed by the browser, the query parameters had to be added to
the xml-stylesheet processing instruction so that the browser correctly
caches the stylesheet. Again, this seems to work perfectly.
 
Now I wonder if anybody else has similar experience with this obvious
approach and what they are. In particular I would be interested to learn
about other browsers which support XSL 1.0 (Opera?, Safari?).
 
I also wonder who is using such an approach in public web applications. I
have never noticed a web app which uses this technology, but due to its
transparency I just might have missed it.
 
Kind regards,
Christian Schlichtherle
-- 
Schlichtherle IT Services
Wittelsbacherstr. 10a
10707 Berlin
 
Tel: +49 (0) 30 / 34 35 29 29
Mobil: +49 (0) 173 / 27 12 470
mailto:christian@schlichtherle.de
http://www.schlichtherle.de <http://www.schlichtherle.de/> 
 

RE: Discussion: Postponing XSL processing to browsers

[Christian Schlichtherle <ch...@schlichtherle.de>]

Hi Philippe,

so far my results have been really great. I've written a complex style sheet
by now which does all the grouping/sorting using strict XSL 1.0 (no Ajax
yet). When the server detects an XSL-capable browser, it responds in about a
1/4 - 1/3 of the time, simply because it can serve the data from the cache
and is relieved from all the complex grouping/sorting.

Of course, one could do the grouping/sorting with Ajax, too. But this
approach still works even if Javascript is disabled and significantly
reduces the required bandwidth. And of course, nothing stops you from adding
Ajax to the stylesheet and hence the resulting (X)HTML.

Kind regards,
Christian

Re: Discussion: Postponing XSL processing to browsers

[Philippe Gauthier - INSERM SIRH <ph...@tolbiac.inserm.fr>]

Hi Christian,

I'm pretty new to Cocoon, but I think postponing the xslt styling is a 
great idea.
After all, the browser is presenting the data, so let it do its job, no 
more, no less.
Plus it'll greatly lighten http transferts by postponing caching to the 
clients.
There might be some security issues and it might become tricky to 
implement with complex workflows, but I'll definitely try it.
Regards,

Christian Schlichtherle a écrit :
> Hi,
>  
> and yet again, it's also possible to embed CSS and AJAX in the 
> resulting page.
>  
> This gives XML + XSL + CSS + asynchronous JavaScript = Web 3.0?
>  
> Kind regards,
> Christian
>  


-- 
Philippe Gauthier
INSERM


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

RE: Discussion: Postponing XSL processing to browsers

[Christian Schlichtherle <ch...@schlichtherle.de>]

Hi,
 
and yet again, it's also possible to embed CSS and AJAX in the resulting
page.
 
This gives XML + XSL + CSS + asynchronous JavaScript = Web 3.0?
 
Kind regards,
Christian
 

RE: Discussion: Postponing XSL processing to browsers

[Christian Schlichtherle <ch...@schlichtherle.de>]

Hi,
 
one more thing: Sending XML+XSL to the client for rendering also enables the
user to save and postprocess the data.
 
Say the content is tabular data resulting from a database query. Now the
client could save it and easily import the data into any XML-enabled
application, say Microsoft Excel.
 
To support this at best, it might be a good practice to embed only authority
based URLs into the XML data and the XSL stylesheet. So when opening the
file in a browser again, the user will see rendered HTML again.
 
(basically you would have served what is described by the term "semantic
web")
 
Kind regards,
Christian