Issues of practicality and scale-up

Subject: Issues of practicality and scale-up
From: CBurdick@xxxxxxxxxxxxxxxxx
Date: Fri, 5 May 2000 15:56:08 -0500
I'll summarize this posting here.  If you're interested, please read on.

Summary Questions and Concerns (these are inter-related):
 - Optimizing code for maximum clarity and brevity
 - Maximizing maintainability over large-scale XML+XSL implementations
 - Avoiding N*M different stylesheets for multiple layers of display context
for the same document
 - Leveraging code reuse and refactoring (http://www.extremeprogramming.org)
 - Toward dynamic XSL

I'm fairly new to XSL, but I've gotten my feet wet.  While there are plenty
of tutorials and examples that show the basics of XSLT to translate *one*
XML document into *one* HTML document, I'm finding difficult to get
information regarding XSLT in practice.

If anyone has comments, tips, follow-ups, or references for any of this, I'm
all-ears!

===================

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.

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)

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?

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.

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

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? 

Sorry for such a LONG post, but I think these are important topics.

Thanks,
Chuck Burdick

------------------------------------
Chuck Burdick
Software Engineer
Britannica.com
cburdick@xxxxxxxxxxxxxxxxx
(312) 356-1541
------------------------------------



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


Current Thread