The primary factor governing the split into modules should be ease of
maintenance. 60 functions in one module seems a little bit large for my
taste (and the larger it gets, the harder it becomes to modularize it), but
it's not unreasonable, especially if the functions are small.

I don't think either of your arguments for making it monolithic are sound.
You could split it into modules, and provide a "front end" module that does
nothing but xsl:include all the others.

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: frank johnson [mailto:fjhnsn@xxxxxxxxx] 
> Sent: 10 March 2009 21:17
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  include multiple utility modules vs one larger one?
> 
> Hello,
> 
> We have coded a number of XSL functions (about 60) used by a 
> series of XSL stylesheets (about 15). We've put all the 
> functions into one large common XSL which is then imported 
> into all the stylesheets.
> 
> This has the effect of including much more into a given XSL 
> than is generally used, but was done to (1) ease the problem 
> of knowing which modules to import into which XSLs and (2) 
> avoid posssible circular references which could result from 
> nested imports. Functionally, our approach has seemed to work 
> well so far.
> 
> Is this considered a best practice or have we implemented an 
> anti-best practice? Aside from an increase in compile time, 
> is there any significant penalty or downside to this approach?
> 
> Thanks in advance.