Re: [xsl] XSLT on the server side

Subject: Re: [xsl] XSLT on the server side
From: "M. David Peterson" <m.david.x2x2x@xxxxxxxxx>
Date: Fri, 2 Sep 2005 23:54:15 -0600
Hi Antsnio,

If I could quickly jump into this and give you some feedback from an
"official" Saxon.NET project standpoint.

- First and foremost, as you know, the advice Dr. Kay gives regarding
XSLT processors of any sort, running on any platform is always going
to be your best bet.
- I really like the emphasis he has put on the idea that when it comes
to your typical transformation needs that don't require extensive
platform integration, using a web service style call to a Java servlet
running on the same server (you might be surprised to learn how much
value using a heterogenous .NET/Java environment using this method can
bring when you couple Saxon with Cocoon, Tomcat, etc...  I've seen
some pretty slick stuff being created using this method and as such,
when appropriate, it is most certainly going to be the correct route
to choose.

- So then when would using this method not be the right choice?

Before I answer this, let me point out that the advice from Sylvain,
Jay, and Dimitre is excellent, and theres nothing more in regards to
the specific areas they focused on that I can add to this
conversation.  There are some general rules of thumb to consider when
trying to choose whether or not to us a Saxon servlet styled solution
or a Saxon.NET solution.  So let me share these with you in hopes they
might help further clarify things in this regard:

     - When you find yourself doing a lot of internal piping of XML
fragments in various stages and formats throughout the .NET platform,
requiring numerous transformations during the overall process.
     - making changes to the structure and/or general output of the
transformed XML to then pass the result back to Saxon.NET via a .NET
XML document type such as XMLDocument(), XMLReader(), or (and this is
really where a lot of power is added to a Saxon.NET-based
transformation) through one of the wonderful .NET XML data type
additions the Microsoft XML MVP's have developed and made available
via the MVP library etc...
    - Caching of XML documents and stylesheets and/or the common
results of such transformations using .NET XML document data types for
reuse by the Saxon.NET library to transform, and/or reprocess the same
sets of documents over and over again, especially when the base of
cached documents becomes large enough such that a need to build a
caching management mechanism is necessary to properly manage what is
what and when to use one or the other based on various criteria.

 Basically, just as Dr. Kay specified... if the desire is to pass an
XML infoset via a file or string object to be transformed via a
transformation file that hasnt been stored as a .NET specific XML
document object of one type or another (making the process of
returning it to its original state to then be recompiled by Saxon near
impossible in many cases) then stick with Saxon proper and a java
servlet approach.

If your needs extend beyond this, a while back I wrote a quick
ASP.NET-based tutorial and usage scenario in which utilizes the MVP
XML core library to add more value and capability to the resulting XML
document type.  The demo takes the result of a transformation and
processes it further, adding things such as the proper document
mime-type information to the response stream, and adding some
additional elements to the XML such that the client properly
recognizes it as an XML file, looking first for stylesheet information
to perform client-side transformations, or styling it with CSS before
passing it to the browsers HTML rendering engine for display.  This
tutorial can be found at the following URL:

> http://www.xsltblog.com/archives/2005/05/first_real_saxo.html

Let me know if you have any further .NET specific questions of which I
will be happy to assist you in any way I can.  Of course as Saxon.NET
is for all intents and purposes Saxon that has simply been recompiled
into CIL instead of Byte-code, anything other than what specifically
applies to the .NET platform and you already know who will be able to
give you the best possible answer/solution ;)

Hope this helps!

Best regards,

<M:D/>

On 9/2/05, Antsnio Mota <amsmota@xxxxxxxxx> wrote:
> Thanks a lot, that really put things in perspective giving me a base
> to proceed. I've forward your answer to my bosses so we can decide
> what to do.
>
> Thanks again for your excelent (as usual) response.
>
> On 9/2/05, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > >
> > > What are the benefits of server-side transforms?
> >
> > You have a lot more control over the environment in which they run.
> > You can filter the data before sending it to the client - security
benefits.
> > You may be able to send less data down the wire.
> > You have access to server-side resources such as databases.
> >
> > > How do i make then?
> >
> > Use any server-side scripting technology such as ASP, JSP, Java servlets,
> > and implement the code to respond to an HTTP request by running a
> > transformation and shipping the result.
> >
> > You could develop this starting from sample code such as the servlet code
> > included in the Saxon distribution.
> >
> > Alternatively, use a package such as Cocoon that already does this and an
> > awful lot more.
> >
> > > Can i call a xslt directly on the server by xmlhttprequest or do i
> > > have to write some server-side component that wraps the xslt? (like a
> > > servlet or asp)
> >
> > You either have to write some server-side code, or find some that someone
> > else has already written.
> > >
> > > I want to keep the server-side processing the most platform-indpendent
> > > as i can. However the company is using IIS and .Net, so how can i
> > > achive this?
> >
> > You'll need to make some decisions, e.g. whether to use ASP or servlets.
> > However, these aren't very constraining if the only thing you are doing
is
> > invoking a transformation. It's quite possible, for example, to run Java
> > servlets under IIS.
> > >
> > > What processors can i use? Saxon .Net?
> >
> > You could, but I don't think I would for this scenario, because you're
using
> > a raft of technologies that you need to master. If you need an XSLT 2.0
> > processor I would run the standard Saxon 8.x release and invoke it via a
> > Java servlet. Saxon.NET might be useful if you want to integrate it more
> > deeply into an existing .NET application. If XSLT 1.0 is OK, use the .NET
> > XSLT processor (System.Xml.Xsl), or use MSXML3/4.
> >
> > Whatever approach you choose, if you have any signicifant level of
> > throughput, make sure that you cache compiled stylesheets in memory
rather
> > than recompiling them on each request.
> >
> > Michael Kay
> > http://www.saxonica.com/
>
>


--
<M:D/>

M. David Peterson
http://www.xsltblog.com

Current Thread