Re: Application Design

[Robin Berjon <robin@knowscape.com>]

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

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

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 <robin@knowscape.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.