XSLT basic philsophy

[Tim Burns <tb...@owlmountain.com>]

Hi,

I have been following this newsgroups and updating my sources diligently and
have a nearly-working application.  Now I am starting to wonder, "What is
the best philosophy for creating XSLT stylesheets?"

It seems that parsing the stylesheet requires quite a bit of overhead, and
so the prudent programmer parses the stylesheet and applys XML
transformations according to some database, LDAP or web session
constructions of the DOM.

This raises questions.  I am starting to think that the way to do XSLT/XML
transformation is to create a catch-all stylesheet that has a variety of
statements like:

<xsl:template match="AuctionPage">
	... do some really cool stuff

</xsl:template>

Each of these transformation applies to some "view" of the website.  The
advantage gained is that you have a single stylesheet template that can be
updated according to changing in the website.  The disadvantage is that you
have some bloat in terms of a single file.  The bloat always gets balanced
by more coding in either Java or C++ in creating a more-complex DOM so that
a variety of different XSLT files can be fed their own XML data schemas.

So, should *.xslt files be treated as web developers used to treat *.xhtml
where each file is some template that is populated by a CGI program, or
should the *.xslt file cover some inter-related subset of the functionality
of a website, or should an entire website be lumped into a single XSLt file?

Thanks in advance.

Best regards,
Tim Burns

Re: XSLT basic philsophy

[Alistair Hopkins <al...@berthengron.co.uk>]

I have a system where if I have a servlet called MyServlet it will compile 
a stylesheet called MyServlet.xsl from the directory I nominate as the 
source for xsl in  my configuration.

This stylesheet does not contain all the XSL as that would be a very large 
and hard to debug sort of a file.  Instead, each logical entity in the 
application (corresponding to a java class) has its own stylesheet, which 
contains a variety of named templates.  So into MyServlet.xsl, I import all 
the templates which correspond to the entity classes which I imported into 
my servlet.

This makes for very easy to manage xsl, as all the stylesheets related to a 
single entity are grouped together, so if you alter an entity, you should 
only have to alter one xsl file.  However, there is overhead, as the xsl 
stylesheet root is a lot bigger than if it was 'inlined', although a lot 
smaller than the 'single stylesheet for a whole application' model.  The 
mean xsl transform time for the last 30 requests was 150ms, as opposed to 
XML generation time of 55ms and a time from entry to exit of the service() 
method of 215ms.  This seems like an excessive amount of time to spend in 
xalan.

The problem I have is that I don't really know where the penalties are.  I 
would assume that there is some internal index of named templates stored in 
a hashtable or something fast to loop through.  So, if I have 30 rather 
than 10 named templates, 20 of which I don't use, it won't really make much 
of a difference.  But then, I also assumed that during compilation, 
attribute sets would be inlined so it would be OK to use them very 
liberally.  I've since discovered this is not true.

Using -Xrunhprof, I find that *most* (non-scientific term) of the top 80% 
of traces relate to string handling in xalan.

What I would be really interested in is a view of what makes xalan slow 
down in its current implementation, what to avoid, and what it is safe to 
use all over the shop.  For example, I have started using entities in place 
of attribute sets and named templates because I know these must be inserted 
at compilation, but it's a nuisance and not really in the spirit of 
XSL.  I'm also curious about how a single stylesheet root behaves under 
concurrent load as it seems to slow down pretty much as soon as I have more 
than a single user on my machine.

I should also say, xalan has worked without bugs, told me in lovely detail 
what's going on when I mess up the XSL, and I'm within my initial targets 
for speed, so I'm certainly not changing...

Alistair

At 04:52 PM 10/31/00 -0600, you wrote:

>Hi,
>
>I have been following this newsgroups and updating my sources diligently and
>have a nearly-working application.  Now I am starting to wonder, "What is
>the best philosophy for creating XSLT stylesheets?"
>
>It seems that parsing the stylesheet requires quite a bit of overhead, and
>so the prudent programmer parses the stylesheet and applys XML
>transformations according to some database, LDAP or web session
>constructions of the DOM.
>
>This raises questions.  I am starting to think that the way to do XSLT/XML
>transformation is to create a catch-all stylesheet that has a variety of
>statements like:
>
><xsl:template match="AuctionPage">
>         ... do some really cool stuff
>
></xsl:template>
>
>Each of these transformation applies to some "view" of the website.  The
>advantage gained is that you have a single stylesheet template that can be
>updated according to changing in the website.  The disadvantage is that you
>have some bloat in terms of a single file.  The bloat always gets balanced
>by more coding in either Java or C++ in creating a more-complex DOM so that
>a variety of different XSLT files can be fed their own XML data schemas.
>
>So, should *.xslt files be treated as web developers used to treat *.xhtml
>where each file is some template that is populated by a CGI program, or
>should the *.xslt file cover some inter-related subset of the functionality
>of a website, or should an entire website be lumped into a single XSLt file?
>
>Thanks in advance.
>
>Best regards,
>Tim Burns