XSLT, the beginning of a new paradigm? (RE: No side effects holy cow. ( Re: process order (still...) ))

Subject: XSLT, the beginning of a new paradigm? (RE: No side effects holy cow. ( Re: process order (still...) ))
From: Khun Yee Fung <KFung@xxxxxxxxxx>
Date: Fri, 14 Apr 2000 10:04:50 -0400
	Isn't XSLT more like Prolog?

Well, XSLT is my current 'the most amazing language'. Giving the title 'the
most amazing language' is my way of saying a programming language has
features so new that it is not even similar to other languages in existence.
Of course, the title is totally associated with my personal experience.
Before 1984, I was only half aware of the programming languages in
existence; I did not use the title then. The first title holder was Simula.
In 1984, Lisp (hey, I was a latecomer) took over. Then prolog took over in
1985. TeX blew me away when I bought Knuth's 'TeX and Metafont' book late in
1985 (it was published in 1979! Knuth changed my outlook on computer science
when I read his paper on parsing before that time. And he changed it again
when I read the book). SASL and Miranda took the title in 1986 and 1987. The
title has not changed until last December when I realized how different XSLT
is.

Maybe it is my imagination again. To me, XSLT represents a very different
way of looking at things. I am talking about the way XSLT handles the
transformation of the input tree to create the result tree. Instead of the
normal procedural way of describing how the result tree is created by
specifying the steps for creating it, XSLT allows you to describe the result
tree in ever more concrete details, starting from the root, to the leaves of
the tree.

Now, maybe DSSSL does it too. But then, the title is a totally personal
thing. And beside, XSLT is in XML so that makes it the second language that
has the data and instruction being in the exact same notation, after Lisp.

Because most programs transform the input to the output in one way or
another, XSLT opens up a new possibility: that of treating the input and the
output as trees. This processing model of XSLT can be extended to handle the
general problem, not just as the transformation language for XSL.

What exactly is this processing model? I am still trying to work out the
details but the most important point is the creation of the result tree as a
traversal of a ever more refined tree. If you want to imagine it as a
cartoon, think of it this way: in the beginning, the topmost level of the
result tree is created by the root template. As each subtree is processed,
the tree opens up like a flower (not exactly symmetrical for sure). When the
full tree is opened up, the process stops and the tree is the result tree.
The tree keeps on opening up if a call-template does not terminate. I am
mixing metaphors here as trees do not open up like flowers but you get the
idea.

It is even more intriguing if you consider the result tree as the center of
the whole processing model. The input tree and the XSLT document tree are
now simply something that help in the process. When the result tree is
opening up, subtrees and nodes are copied from the input tree or the XSLT
document tree to the result tree. This is how the result tree receives more
and more details.

The second exciting thing about XSLT is the use of a template as the basic
code unit. Using a template as the basic code unit opens up new
possibilities. For instance, ever since the beginning, names have always
been used to identify code units in most languages. Now, in XSLT, the code
unit can also be referred in runtime according to a different criterion, the
pairing of a new current node and a template whose `match' attribute
evaluates to a node-set including the new current node when using the old
current node as the context node.

Other implications go on and on. But I will stop now. Sorry for sending such
a long message. Although almost 6 months have passed, the excitement is
still very intense.

Regards,
Khun Yee


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread