Approaches

James Tauber

I've found it particularly useful with documents to go from content-based markup to structure-based markup with one stylesheet and structure-based markup to presentation-based markup with another.

Mike Brown added an excellent approach

This came about answering specifics re scalability etc, but is quite useful as a general approach to the use of XSLT. As a later correspondant put it, pick your tools wisely and remember that just because you have found a shiny new hammer, not every problem becomes a nail. On the other hand there are an awfully large number of nails lying around waiting to be hit :-))

These questions are related and the problems are mostly resolved by changing your view of what you think of as "data" and what you think of as presentational components that belong in a stylesheet.

> Suppose you want to allow people to apply personal preferences to the
> display of a document.  Suppose there are N such preference types.

This is information you can collect and put into XML documents.

> Also you want people to view the doc in different mediums: over the
> web, on their fancy-cell-phone, or whatever.  You have M such media.  It
> seems that now you have to make N*M different stylesheets to accomodate
> these display representations of the same document.  

Components of desired output documents can also be modeled with XML and XHTML. The stylesheets can be devoted mainly to presentation *logic*, and most of the actual presentational content can be obtained from XML/XHTML. The document() function is very, very useful!

> What happens when many of the stylesheets have major similarities?  If you
> want to make a change, how do you avoid having to propogate the changes
> through each stylesheet?

Put that stuff out in XML, not in your stylesheet, and have the stylesheet go look up the information it needs based on user preferences, which is also going to be in the XML.

> What happens when you want to internationalize to L different languages?

Again, have your stylesheet just be code that goes and gets what it needs from the XML/XHTML.

> 4.  Code reuse and refactoring.
>
> The problem with [one template with many conditionals] 
> is that the code gets nasty and unreadable very quickly.
> The problems with [many templates] are that you often replicate code

I prefer many templates. When I need to replicate code, I use calls to named templates, sometimes with parameters if there are slight variations that need to be accounted for. Named templates provide the equivalent of subroutines or private methods.

> and there is no 'otherwise' clause to catch things that fall through
> the tests.

Which tests, the match attributes on xsl:template elements? Say you want to process 'foo' elements, and you want to have one template for when foo's 'name' attribute is 'bar', one template for when it's 'baz', and one template for all other 'foo's:

<xsl:template match="foo[@name='bar']"/>
<xsl:template match="foo[@name='baz']"/>
<xsl:template match="foo"/>

And these are in addition to the built-in template that matches "*" (any element). The templates with the greater degree of specificity will have higher priority for matching.

> Have people been able to move towards dynamically-generated XSL so that some
> of the contextual complexities of the above issues can be automated? 

I would guess that you are not quantifying enough of your data in XML. Presentational data is data, too. Put it in separate XML documents and let your stylesheet use the document() function to access it and merge it all together with your "data data".

At some point, though, you have things that need to be dynamically generated, and for this my solution for now has been to just bite the bullet and write custom templates. But I've abstracted 80% of the commonalities out of these templates and modeled as much data as I can in XML, cutting down the size and redundancy of the custom XSL templates by orders of magnitude.

Now, if you were naughty and neglected to mention that you are restricted to using the stock MSXML that comes with IE5, ignore everything I've said here. :)