Re: [xsl] Rescuing XSLT from Niche Status

Subject: Re: [xsl] Rescuing XSLT from Niche Status
From: "Michael Beddow" <mbnospam@xxxxxxxxxxx>
Date: Fri, 16 Feb 2001 21:45:39 -0000
On Friday, February 16, 2001 8:18 PM
Roger L. Costello wrote:

> A colleague of mine has written an excellent paper describing a new
> of looking at creating XSLT documents.  I think that you will find
> paper very thought provoking.

Well it certainly provoked some thoughts in me, above all, how can
anybody really think this is new? Dig back into some of the earliest
layers on the Microsoft xml site and you'll find "introductions" that
are entirely built around this pull approach, written by people who
thought this was just a sort of ASP with a few more funny brackets in
slightly different places.

And, from my admittedly limited experience of trying to teach people
XSLT, I find that if they're encouraged to do things this way from the
start they certainly start off happier and see results faster, but
eventually they ask, why not just use PHP, which has a simpler syntax
and is more tolerant of trial and error (i.e. if you get something
nearly right you get some sort of results, whereas write select =
"gunge" when you meant select="'gunge'" you'll be staring at zero
output). And I don't have an answer to that question if XSLT is
understood as a scripting mechanism, not as a tool for styling in the
broadest sense.

I'm not sure XSLT really is in a "niche" from which it needs rescuing.
This group is one of the most interesting ones I know because it's
highly specialised but not at all cliquey: passers-by, even with the
daftest FAQ's, are made to feel at home.  And above all a lot of the
more technically abstruse responses are invited by problems that are
themselves intrinsically complex, and couldn't be solved by a subset
of XSLT practices that tried to be indistinguishable from html
scripting languages. OK the paper is just saying, "this is a more
promising starting point"; but I'm not convinced that if you make such
a big thing of *that" as a starting point people are ever going to get
as far as they might if the full power (and therefore difficulty) of
the thing is plain from the start. Consider how many of the problems
that crop up here come from people thinking of XSLT as filtering an
input stream into an output stream instead of transforming one tree
representation into another. So the S and the T are both important,
and I don't think it's kind to keep them hidden too long from

Michael Beddow

 XSL-List info and archive:

Current Thread