[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: "Soumitra Sengupta, Ph.D." <email@example.com>
- To: Mike.Champion@SoftwareAG-USA.com
- Date: Sat, 11 Aug 2001 14:52:11 -0500
>> 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
> 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.