This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Issues of practicality and scale-up
- To: xsl-list at mulberrytech dot com
- Subject: Re: Issues of practicality and scale-up
- From: Matt Sergeant <matt at sergeant dot org>
- Date: Sat, 6 May 2000 10:55:42 +0100 (BST)
- Reply-To: xsl-list at mulberrytech dot com
On Fri, 5 May 2000 CBurdick@us.britannica.com 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