[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: Paul Tchistopolskii <email@example.com>
- To: Don Park <firstname.lastname@example.org>, email@example.com
- Date: Sat, 11 Aug 2001 18:41:47 -0700
> > XSLT is an example of a 20/80 point technology:-) It
> > gets you 80% towards a solution quickly but makes the remaining
> > 20% either impossible or so hard that the time it takes to get
> > that last 20% done, wipes out the gains you made on the
> > first 80%!
> I agree completely. Even worse, XSLT is pretty low in the list of 'things
> This means that, in most situations, there will not be anyone to maintain
> XSLT-based solutions.
I think that the problem with XSLT is that XSLT
is often misleading, pretending to be more
'powerful' and 'portable' than it actually is.
This statement does *not* equal to
"XSLT is a uslesess crap, don't use it".
> 1. level of expertise needed to use.
> XML-DSIG or XKMS implementations are usually hidden behind APIs which can be
> used without knowing much about XML-DSIG or XKMS. XSLT, XLink, and XML
> Schema are more 'hands-on' tools which you are likely to be using everyday.
> You cannot use them without investing time to learn them.
I'd talk about XSLT. One *can* use XSLT *not* investing too much time
Here is how:
1. XSLT has a few reasonable and intuitive
constructions and concepts, that one can (and I think should)
learn in one day, but also XSLT has lots of garbage that nobody
can guess how to use until reading the entire ( brilliant ) book
by Michael Kay. The book is heavy. That's not because
Michael is a bad writer, but because XSLT in it's full glory
Those, saying that "XSLT is easy", they usually either don't
know XSLT *or* they are some LISP guys, who just like to
feel smarter than "average procedural Joe developer".
2. The XSLT constructions one can ( should ) learn are :
-1. Basic, as trivial as it's possible XPath subset +
current(), text(), string operations, document( url )
0. xsl:template ( 'match' only. No 'name', no 'mode' )
1. apply-templates ( no 'mode' )
4. sort ( for (a) and (c) ).
5. copy-of and copy ( better not to waste the time,
trying to understand what xsl:copy is, just learn some
magic patterns of using it ).
6. xsl:include ( no xsl:import e t.c.)
7. xsl:param for the stylesheet.
8. xsl:variable ( unavoidable. Have to understand that variables
are not the variables, actually ).
9. xsl:element and xsl:attribute
10. Better not to use XSLT for things other than generation of
HTML/XML, but in case you do - you have to learn xsl:text and
blindly use it everywhere, where whitespace is important.
One may think that the above subset describes XSLT as it
is, but that's not really true. Recursion is out, many other
'neat' things and 'practices' are out e t.c.
And one more thing... Always validate the result of XSLT
transformation. Or get used to broken pages, because
XSLT silently forgives any mistake you may make, including
mistyping of one letter in almost any critical place of the stylesheet.
3. XSLScript exists, which allows readable call-template,
but if not using XSLScript - better *not* to use call-template,
but instead :
a. Use pipes of transfromations.
b. Write plenty of low-level functions in Java.
Yes, this will not be portable between the engines, but those,
who say that 100% complaint complex XSLT stylesheets
*are* portable between different XSLT processors are
wrong ( sometimes they're wrong on purpose, I think ).
Porting a set of *complex* XSLT stylesheets from one
"100% W3C standard XSLT processor" to another
"100% W3C standard XSLT processor" is and
will be a darn hard work, comparable to porting of
the low-level functions.
Doing something more complex than reordering
a few branches and / or renaming / adding / supressing
some elements / attributes ? Don't do it in XSLT.
You can ( long ago, Oren has written the
8 queens puzzle in XSLT, demonstrating
that one can do anything in XSLT )
but it will not be readable, it will not be reliable,
it will be slow e t.c.
1. Either try to decompose your processing into
the pipe of components, where some components
are plain brutal XSLT ( described above ) , but some
components are just perl scripts or
2. Write tons of fuctions in low-level language, so
that XSLT stylesheet will just traverse a tree,
passing node-sets to the low-level functions
( *with* side-effects ).
3. Also one can give up and just start
using SAXON's extensions. This is
the most practical usage of XSLT, but
I guess it is not "really cool" to do that.
This view does not work on 'client side'. Client side
XSLT does not exist anyway. In the case when it does
exist, just a subset of XSLT ( described above )
> 2. rate of change
> Anything built with XSLT, XLink, and XML Schema are likely to require
> constant maintenance. This means you must have the expertise in-house.
I'm sure there is very limited number of people in this world, who
can understand some ( neat ) XSLT stylesheets, written by
Steve, Oren, David, Jannie and some other posters of XSL-list.
Supporting huge and complex system written in XSLT ?
Priceless opportunity. Too bad nobody needs XSLT coders.
DICE has zero contracts for XSLT coders. Me thinks that's
because nobody is using XSLT for anything, but rendering
trivial pages in IE.
> Building a city is easier than running it. If you are going to build Rome
> in a day, make sure there are plenty of plumbers.
I think there is plenty of jobless plumbers already.
Should not be a problem.
PS. I can do anything in XSLT, but in recent projects
I prefer to stay away from it, even ( and also because )
I had an experience of embedding 3 different XSLT
processors into 5+ projects.