[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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)
who to scale up apache
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.