OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Application Design

Mike.Champion@SoftwareAG-USA.com wrote:

>> XSLT is an example of a 20/80 point technology:-) 
> For what it's worth, I'm predisposed to consider XSLT (along with "common"
> XML 1.0, DOM, and XPath) as part of the solid core of XML technologies that
> really more or less do what they are advertised to do and have a real track
> record of success. 

I agree.  I am afraid (from the questions I see on the XSL List) that 
lot of people are trying to use it as
a general purpose scripting language.  If you stick to transforming 
trees and generating XHTML with it,
I have found it to fall well within the 80/20 rule.  Norm Walsh's 
DocBook is a fairly comprehensive and
complex DTD.  One can learn a lot from the set of XSLT stylesheets that 
was written to transform a
DocBook document into HTML.  What we now need are tools with XPath 
wizards that lets you
build a stylesheet and I think a few attempts are being made at this 
right now.

> I'd be very interested in hearing from people who have tried to implement
> more complex XSLT applications. When does XSLT generally hit the wall?  

This is by no means complete.  But if we use some guidelines, we can get 
XSLT to do the tree
transforms fairly easily and elegantly:

1. Do not try to use it as a programming language
2. Break up the transform into steps and concentrate on getting the 
input XML into closer and
closer to the output
3. Learn how to avoid using for-each, choose etc.  Once you start using 
these frequently, you
would be tempted to suddenly switch into a general purpose programming 
language mode.  Use
these as a last resort.
4. If you are familiar with Lisp, you have a better chance
5. Try not to take a flat XML and convert it into very deeply nested 
structures.  We have done
a few implementations where a flat Headline and para structure had to be 
transformed into nested sections
as per DocBook based on whether it was Heading 1 or Heading 2 and so 
on.  It was pretty
complex.  Similarly it is hard to generate nested lists.

Typically large documents and very large monolithic stylesheets cause 
the biggest problems.  It is
hard to do a trace once you discover a bug.  Point 2 should keep you 
from getting into
this problem.  The 2 things we did in our Xfinity Server that has helped 
us a lot are caching compiled
stylesheets and breaking transforms down into steps and piping and 
splitting them (when it is feasible).
This has 2 benefits,  a) it uses less memory b) encourages reuse of 
templates ala components.
We have used XSLT extensively in several implementation and typically we 
use it in conjunction with
Servlets and JSP and our server.