Re: Issues of practicality and scale-up

Subject: Re: Issues of practicality and scale-up
From: Matt Sergeant <matt@xxxxxxxxxxxx>
Date: Sat, 6 May 2000 10:55:42 +0100 (BST)
On Fri, 5 May 2000 CBurdick@xxxxxxxxxxxxxxxxx wrote:

> It seems that with XSL, many of us have taken a step back from the
> convenience we are used to from Perl and Python and other tools for web
> develpment.  XSL is a kinda-sorta programming language, but has severe
> limitations compared to other full-fledged tools we are used to.
> 
> Issue items:
> 
> 1. Limited function availablity.
> 
> This leads to complex and kluge-y XSL code.  (And I thought the days of that
> were past with "modern" languages like Python.)  Examples: 'or' is
> exclusive-only, no 'random()', 'translate()' is *horribly* weak and
> un-useful, no easy ways to check if 'element' is a member of 'list'.  To get
> the desired outcomes, the programmer has to hack a workaround and break the
> clarity of the code.

While XSLT is a standard, you shouldn't consider it the only
option. Standards are good - they mean you code will work everywhere. But
if you're interested in something with all the flexibility of Perl, and
the node resolution of XPath, and the apply-templates like functionality
of XSLT, maybe XPathScript will interest you. It's part of the AxKit
project: http://xml.sergeant.org/axkit/

> 2. Maintainability
> 
> OK so you can use <xsl:include/> and <xsl:import/>, but in practice, how do
> people put together a useful mesh of these to create a complete app?  What
> happens when you have many inter-related stylesheets?  (Also see next items)

Take a look at Norm Walsh's modular docbook stylesheets. They are an
excellent example of modularisation and reuse - even if they are a
nightmare to follow for a layman ;-)

> 3. The N*M problem.
> 
> Suppose you want to allow people to apply personal preferences to the
> display of a document.  Suppose there are N such preference types.  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.  
> 
> 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?  What happens when you want to internationalize to
> L different languages?  Now do you have N*M*L stylesheets?  Do you end up
> making 3 XSLT transformations instead, each time moving to an intermediary
> DTD?

While this is a problem, you have to realise the scale of the problem this
is actually solving! You don't have to have N in that equation. And
certainly, N will probably _only_ be a factor for "screen" media types for
most people. L should be solved using content-negotiation *NOT* XSLT,
IMHO.

> 4.  Code reuse and refactoring.
> 
> On the micro scale, this problem often occurs often when you have choices to
> make within a template.  As discussed elsewhere on this list, you basically
> have to routes: Make one <xsl:template select="thingy"/> with many ugly
> intersprinkled <xsl:choose/> snippets, or you create several <xsl:template
> select="thingy[SOME EXPR]"/>.  
> 
> The problem with the former is that the code gets nasty and unreadable very
> quickly.  The problems with the latter are that you often replicate code in
> each <xsl:template/> that could and should be refactored, and there is no
> 'otherwise' clause to catch things that fall through the tests.  
> 
> Both of these methods are aggravated by item (1) above.  Without powerful,
> eloquent functions and capability, your 'select=' and 'test=' arguments get
> long and unwieldly (and difficult to debug) very quickly.

See AxKit - I figure you might actually prefer XPathScript. All of this is
possible. (xml.sergeant.org is all dynamically generated with AxKit and
XPathScript).

> On the macro scale what happens when you have many XSL stylesheets that have
> similar code?

There you use <xsl:include..> but as you already pointed out - that has
its weaknesses. My problem with XSLT is it's a programming language, but
without the features of 99% of modern programming languages. Still, AxKit
supports XSLT if you want to go that route ;-)

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

Sure. See Cocoon: http://xml.apache.org/cocoon/

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread