Re: Application Design

[Paul Tchistopolskii <pault12@pacbell.net>]

> > 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
> to learn' for average engineers unlike Java, JavaScript, HTML, and XML.
> 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". 

Elaboration follows.
 
>  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 
learning it.

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 
*is* *hard*. 

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 ) 
form only.

0. xsl:template ( 'match' only. No 'name', no 'mode' )
1. apply-templates ( no 'mode' )
2. value-of
3. for-each
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.

<conclusion>

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. 

Instead 

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 ) 
should work.

</conclusion>

>  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.

Rgds.Paul.

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.