XSLT & hello

[Maxim Dounin]

Hello!

On Tue, Apr 08, 2008 at 06:32:57AM -0400, Denis S. Filimonov wrote:

>I second that. XSLT really belongs to the application level. For instance, you 
>might want to allow users to select different stylesheets for the same page 
>(e.g., different skins). If you offload the XSLT outside your application, 
>you lose this ability.

Not really, since you can control what happens via external means 
(X-Accel-XSLT?) or even internal XSLT means (see thread for 
xslt_root proposal - but personally I think it would complicate 
[efficient] implementation too much).

>Besides, I don't think nginx would be able to do it considerably faster, it'd
>probably use the very same libxslt.

The main thing nginx can do to speed up things is XSLT parsing / 
caching.  This may be sometimes tricky at backend level.

But this is definetely not the argument for XSLT itself.  If you 
need speed - you don't use XML.  :)

My main motivation for nginx xslt module is to do things 
simple, manageble and interoperable.

Maxim Dounin



>
>On Tuesday 08 April 2008 06:08:04 mike wrote:
>> Again - I see this as being still making sense to reside in the
>> application layer, since the possibilities of inputs and outputs are
>> infinite (well, could be...)
>>
>> I'm not sure the browser reliably reports it's XSL processing
>> capabilities without using JavaScript, in which case, you've probably
>> already side-stepped the webserver (or, you have to use all this in
>> combination with each other)
>>
>> I don't believe there is still any consistent client-side XSL that can
>> be adopted that is safely cross browser and such. Last I checked
>> Google had an XSL processing library that was as close to
>> cross-browser as it got, but it still wasn't 100%.
>>
>> I'm not saying it's not worthwhile for some folks. I am just not sure
>> it's meant to be in an nginx supplied module. Extensions obviously
>> anyone can cook up for any reason... and XML/XSL offloading is a
>> common desire (ZXTM does it, there's some hardware appliances even
>> that will do it for you) - someone has already said they'd love it for
>> their application - the need -is- there, but I'd rather it be
>> something external to core nginx development as there are some other
>> features that should reside in the server that have not been finished
>> yet...
>>
>> On 4/8/08, Chris Farmiloe <chris at oxdi.eu> wrote:
>> > The main benifit I'm after is being able to decide from the nginx.conf
>> > something like this (pseudo):
>> >
>> > if($user_agent is unable_to_perform_xslt){
>> >   xslt on;
>> > }
>> >
>> > This would allow me to offload the majority of the XSLT processing
>> > client-side, but still support some of the older browsers, text-only,
>> > screen readers etc.
>> >
>> > I'm also a fan of a complete separation from application level code...
>> > although XSL is about presentation, XSLT is simply the process of
>> > conversion and unlikely to need modifying.
>> >
>> > I see you're point about converting between random formats, but if you
>> > think about it... YES... if there was an XSLT module you could handle
>> > almost any output you could create with XSL. and maybe even override
>> > the style-sheet to use ie..
>> >
>> > location ~* .csv$ {
>> >  xslt on;
>> >  xslt_stylesheet /xsl/csv.xsl;
>> > }
>> >
>> > It could allow you to create application servers that only talk one
>> > language (XML) while allowing you to still build REST style services
>> > that respond to multiple content types.
>> >
>> > chrisfarms.
>
>
>
>-- 
>Denis.
>