[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: Robin Berjon <email@example.com>
- To: firstname.lastname@example.org
- Date: Sat, 11 Aug 2001 22:58:42 +0200
On Saturday 11 August 2001 17:58, Mike.Champion@SoftwareAG-USA.com wrote:
> > If only the world were so simple!
> So, let's make it that simple :~) Maybe XSLT isn't what we really need,
> but maybe there's a subset of XSLT that hits the 80/20 point, or maybe
> there's a more elegant alternative that does what we hoped XSLT would do.
There is definitely (imho) a subset of XSLT that meets the 80/20 point. What
I like about XSLT is that it is strict. While strictness is definitely a bad
thing in _general_ purpose solutions because you loose the security of being
able to find your own solution to the problems that the inventors of the
solution hadn't thought about (eg the bondage & discipline programming
languages), it is a great thing to have in special purpose solutions, the
ones you want to do one job and do it well.
XSLT for me falls into that latter category. It transforms trees and does it
reasonably well (albeit, of course, with a few limitations, but that's what
80/20 is all about). Anyone trying to do anything else with XSLT is bound to
run into the same kind of problem as someone trying to light a cigarette with
a coffee mug (don't ask): it may work but you don't want to know how.
> 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'd agree with that.
> 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? Is
> there an alternative (given than you have XML data as the input) other than
> just writing code? (For example, does anyone other than Al Snell find PHP
> templates to be a more powerful, easier to use alternative?) How do people
> feel about XQuery's output reformatting capabilities as an 80/20 point for
> real-world web applications?
I've been using XSLT intensively for a number of months, and have clearly hit
some walls. I still consider it to be too young a technology (for me at
least) to be able to produce guidelines, but some elements are starting to
For instance, using XSLT to produce similarly or less complex documents than
the original is easy, trying to produce a document that's richer than the
original will likely lead to problems. That's to be expected, after all the T
does stand for transformation, and not for destruction or for production.
Whatever information you want in the output should be present more or less
as-is in the input. This is obvious but a lot of people tend to forget it.
Problems relating to producing some types of tabular documents are well known
(and addressed in the XSLT 2.0 requirements) so I won't go into them here
(though I've been badly bitten by them, and resorting to xsl:text +
disable-output-escaping + CDATA is something I'd rather not think of during
One major problem I'm seeing presently with XSLT is that of the compared
document orders of the source and the output. If they differ too greatly, or
in some specific ways (of which the tabular example is just a specific case)
then you'll end up using far too many value-ofs and copy-ofs, and worse, far
too many call-templates. I'm actually on the verge of saying that an XSLT
document is as good as its density in apply-templates. Of course, that would
be an exageration as the other ways to jump accross templates are useful
there, and in fact XSLT would be pretty much useless without them. However,
too few apply-templates in an XSLT document probably means that you should be
using another language optimized for another processing model. At least it
should raise a warning of whether you're doing it right.
As for PHP templates (I haven't used PHP, but I'm talking from experience
with the 200 or probably more templating modules -- some of which are truly
excellent -- that can be found in the Perl community, and more precisely on
CPAN) I think that they serve a different role from XSLT (and unfortunately
the word templates or even templating system is used in both, causing
confusion). The template modules such as those made for Perl are very good at
dealing with *text*. In fact, they are far better than XSLT is at a number of
tasks. They are general purpose solutions, and they can do just about
everything, but they're favoured output format is text, not XML. And because
of that, there is no serializer that takes care for you of issues such as
encoding, tag pairing, escaping, etc. XML is much more than just text, and
that's where XSLT fits in.
If I had to query a remote SOAP server, grab something from a database,
update an object repository, and feed the results to a webpage I'd definitely
use XSLT only as the very last step. The first ones would be carried out in
Perl (replace with your favourite general purpose programming solution),
probably used through XSP (in order to garantee valid XML output). XSLT would
simply transform the programmatic structure produced by my application into
another structure, fit for consumption by browsers/users. Any alteration of
the said structure would probably have to happen within a space within which
I have more control.
So I guess the best practice here is (surprise !) "apply where appropriate".
Robin Berjon <email@example.com> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
The first myth of management is that it exists.