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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Issues of practicality and scal, Jonathan Borden | Thread | Attachments are banned from the XSL, XSL-List Owner |
Re: Attachments are banned from the, Martin Stricker | Date | XML to XPress or Flash, Sydney |
Month |