Whats so great about xsl anyway? :-)

[Simon Harvey]

Hi everyone,

I am fairly new to learning about xsl and xml, but one thing I have noticed
is that anyone offering a tutorial or lesson on it seems to think that its
the most incredible invention ever made.

I don't.

I'm wondering what everyone else thinks. I know the smart answer is, use it
if you need it and don't if you don't.

Heres my situation. My boss is the MD of a localisation company - they
localise software and training manuals and so on (translation mainly). Now,
my boss has got it into his head that xml is just the bees knees and should
be applied anywhere and everywhere. He wants me to make him a multilingual
content management system using xml and probably xsl.

Can you think of any reason to do this?

I understand that it would be helpful to seperate presentation and content -
exactly what xslt achieves. But it just strikes me that the price is way way
to high - sure it can seperate, but its hard! I can't even make simple html
docs using xslt. And I doubt many other people can either. So, I'm pretty
worried that if I were to somehow manage to make a decent website using
xslt, anyone who wanted to make even the simplest of changes would need to
know a pretty difficult, hard to understand and obscure technology.

Does anyone else think the xslt hype is just that - hype. Sure it would be
ok for sites that are maintained by legions of programmers and it would be
rather useful if you wanted people with phones to look at your site - but
lets be honest - how many of you think that your site would be great on a 2
inch screen.

Please share your thoughts and lets see if we can't get down to the bottom
line

Kindest Regards to Everyone

Simon

 

[Chris Barber]

XSLT [aka. XSL, XSL Transforms] is a pain in the ass to get to grips with
(mostly cos of the lack of 'classic' program flow logic and string stuff)
that make it look and feel very alien to a traditional scripter /
programmer.

However, there is a reason for that - something to do with a structure that
allows a free association between XML elements and how they should be
'converted' and processed.

My 2 cents: get a book on XML and XSLT and *read* it - don't just leave it
on the side in the bathroom - take the time to really read it and try to
grasp the fundamentals behind templates as a starter.

I have achieved HTML stuff using XSLT that I could only dream of with
classic ASP simply because of the built in recursive nature of XSLT
templates.

That doesn't mean that all I do now is XSLT! If I did that I'd never get
anywhere. XSLT has a serious lack of good program flow logic capabilities
and certainly falls down on string processing and variable scoping (because
of its platform generic and 'no-errors' design I believe).
So .... a mix of ASP, VBScript, XML, XSLT and JavaScript is the end result,
each doing what it's best for.

Note: Dimitre, Oleg, everyone - my apologies for any unintentional misuse of
XML and XSL terminology or descriptions of the inner 'workings' design goals
of XSLT (eg. the 'no-errors' bit).

Chris.

Hi everyone,

I am fairly new to learning about xsl and xml, but one thing I have noticed
is that anyone offering a tutorial or lesson on it seems to think that its
the most incredible invention ever made.

I don't.

I'm wondering what everyone else thinks. I know the smart answer is, use it
if you need it and don't if you don't.

Heres my situation. My boss is the MD of a localisation company - they
localise software and training manuals and so on (translation mainly). Now,
my boss has got it into his head that xml is just the bees knees and should
be applied anywhere and everywhere. He wants me to make him a multilingual
content management system using xml and probably xsl.

Can you think of any reason to do this?

I understand that it would be helpful to seperate presentation and content -
exactly what xslt achieves. But it just strikes me that the price is way way
to high - sure it can seperate, but its hard! I can't even make simple html
docs using xslt. And I doubt many other people can either. So, I'm pretty
worried that if I were to somehow manage to make a decent website using
xslt, anyone who wanted to make even the simplest of changes would need to
know a pretty difficult, hard to understand and obscure technology.

Does anyone else think the xslt hype is just that - hype. Sure it would be
ok for sites that are maintained by legions of programmers and it would be
rather useful if you wanted people with phones to look at your site - but
lets be honest - how many of you think that your site would be great on a 2
inch screen.

Please share your thoughts and lets see if we can't get down to the bottom
line

Kindest Regards to Everyone

Simon

 

[Dimitre Novatchev]

I have achieved HTML stuff using XSLT that I could only dream of with

classic ASP simply because of the built in recursive nature of XSLT
templates.

That doesn't mean that all I do now is XSLT! If I did that I'd never get
anywhere.
XSLT has a serious lack of good program flow logic capabilities

There's simply no concept of "program flow" in a functional
programming language if by "program flow" you mean order of execution.

And this is not a shortcoming but a serious advantage, because it
frees the programmer from thinking in an imperative, state-based
sequential fashion and gives the compiler a greater opportunity for
optimisations.

and certainly falls down on string processing and variable scoping

A functional programming language allows particular functions to be
defined for string processing. A string is a list of characters and
any FP function working on a list will also work with a string. The
FXSL library (written in pure XSLT) provides some basic primitives for
processing strings (e.g. generic recursion over the characters of a
string, mapping a string, zipping two or more strings, string
tokenisation, ... etc). It has been used for such tasks as line
justification, spelling checking and generation of correct close words
for a misspelled one.

As for the problems you have with the variable scoping in XSLT I can
only guess.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Simon Harvey]

Hi Guys,

Ok, thanks for that. I thought that would be the rough answer.

The other big part of this story though is how the decision of using xslt
will effect changes to the site. As I said earlier, its alright for a
company with a dedicated IT unit that can make changes and develop new
techniques. But what about a small company who get a contrator in to make a
new site for them.

This is the situation I'm in. They want a content management system and I
can obviously only provide them with so many templates. So what if they want
to make even slight changes. Most non-techs can find html plenty hard enough
never mind a sifnificantly harder langauge and process.

Do you think I am over complicating things here?

Thanks all
Simon

 

[Simon Harvey]

Chris,

You've mentioned some stuff that xsl can do that you couldnt do with asp or
some other traditional tech. Can you give me a simple practical example. By
practical I mean something that would actually make a real difference to my
site, as opposed to just some neat processing trick that arrives at the same
conclusion. That would be greatly appreciated.

I understand what you are saying about xsl. Essentially I have come to the
conclusion that xsl is very helpful to large and well resourced sites, but
to the small site with no xslt developers, its completely useless. I can't
be bothered with writing xslt, so why would non tech people who just want a
simple yet easy to use website.

Simon

 

[Chris Barber]

Example of XSLT benefit.

A searchable treeview with just two templates (node and leaf), a bit of
client side JavaScript, and a single XSLT parameter (the search term). I'll
email you the development sample if you want me to.

Previously I had about 200 lines of ASP and it was horrendously
complicated - the XSLT method is so elegant and easy to debug.

I also work with a GIS product (ArcIMS) that generates XML as is main
communication method. I have used XSLT working directly on the XML to
display interactive legends for the maps generated. The XSLT templates can
match a specific element that occurs anywhere in the document do no need for
loads of:

If (something exists) Them
Call This Routine
End if

everywhere.

The biggest benefit to me in the current application is that I can
dynamically show different 'editing' views of a specific XML document (that
controls the display of the map) by loading the XML once and selecting
specific XSLT files, running the transform client side and putting the HTML
into a DIV section. It works extremely well and once you have done 1 XSLT
the others are simply a case of editing the 'template' to suit (very fast
development cycle).

I can let you see it in action if you really want to (email me if that's the
case and I'll arrange a login for you).

Chris.
Remove the .NOSPAM to email me.

Chris,

You've mentioned some stuff that xsl can do that you couldnt do with asp or
some other traditional tech. Can you give me a simple practical example. By
practical I mean something that would actually make a real difference to my
site, as opposed to just some neat processing trick that arrives at the same
conclusion. That would be greatly appreciated.

I understand what you are saying about xsl. Essentially I have come to the
conclusion that xsl is very helpful to large and well resourced sites, but
to the small site with no xslt developers, its completely useless. I can't
be bothered with writing xslt, so why would non tech people who just want a
simple yet easy to use website.

Simon

 

[Simon Harvey]

Hi Chris

That would be great. Very much appreciated.

Please email me at sh856531 at microsofts free email service .com

If you don't want to post a login here

Thanks again chris. I'm glad xslt is working so well for you!
Simon

 

[Sebastian Schaffert]

Hi everyone,

I am fairly new to learning about xsl and xml, but one thing I have
noticed is that anyone offering a tutorial or lesson on it seems to think
that its the most incredible invention ever made.

I don't.

Me neither. And I've known it for many years and actually teach it to
students. XSLT is one of the most badly designed languages out there. It's
too expressive and complicated for a stylesheet language and too
unconvenient for a programming language.

Nonetheless, XSLT is the only language currently available for querying and
transforming XML data (besides directly working on the DOM).

XML, on the other hand, is merely a syntactical means of representing
tree-structured data, and in that it has several advantages over relational
database systems.

BTW: Actually, I am working on something different (http://www.xcerpt.org),
but this project is currently mainly a research issue and not well suited
for day-to-day work.

[...]

I understand that it would be helpful to seperate presentation and content
- exactly what xslt achieves.

No, it is independent of XSLT, it's merely a good design principle and
applies to any form of programming.

But it just strikes me that the price is way
way to high - sure it can seperate, but its hard! I can't even make simple
html docs using xslt. And I doubt many other people can either.

I can guarantee you that many people have difficulties with XSLT. On the
other hand, for many tasks you could simply use XML+CSS which should be
understandable by most people and still gives you the possibility to
annotate your data with tags that have semantics other than presentational.

 

[Bob Foster]

BTW: Actually, I am working on something different (http://www.xcerpt.org),
but this project is currently mainly a research issue and not well suited
for day-to-day work.

Is that link correct? Can't seem to connect to it.

Bob

 

[Dimitre Novatchev]

In my opinion, XSLT is *not* a functional language, despite the fact that

many people try to attach this property to it. XSLT lacks many features
that are well accepted nowadays as being properties of functional
languages:
- static type system
- higher-order functions

Thank you for your opinion. I dare to give more waight to one of the best
specialists in the area of FP, Phil Wadler, who very firmly stated (a year
ago at the last Summer School in Functional Programming, in Oxford) that
XSLT is a functional language and is the most used functional language.

Probably there's just a terminological difference between you two, but
permit me to accept Phil Wadler's statement.

He is one of the creators of another functional language -- XQuery. Once
again, XQuery is a functional language according to Wadler, although it
lacks higher order functions.

Also, functional recursion (i.e. not structural recursion over the input
tree) using <xsl:call-template> is a pain-in-the-ass (just have a look at
your foldl example in fxsl).

I feel sympathy for your pain. In XSLT 2.0 one can define an xsl:function
and then reference it directly in an XPath expression, without the need of
xsl:call-template. BTW, XSLT 2.0 also has static type checking.

As for feeling pain when having to use xsl:call-template recursively, I
haven't heard such an opinion in the xsl-list for almost three years. Some
people feel uncomfortable about recursion in general, but nobody has voiced
any concerns about xsl:call-templates.

Your feelings are something relative and personal. I understand that a
programmer, having been trained in an imperative language, would be
uncomfortable with recursion.

In the same way a programmer trained in an FP language would feel very
uncomfortable having to assign new values to variables and to remember what
state is associated with which value of a variable.

Hundreds and hundreds of young people trained in an FP language (several
universities teach an FP language as a first programming language) will feel
similar pain if they are forced to use an imperative language.

The fact that you can express functional design patterns in XSLT does not
make it a functional language. You can also use these patterns in C.

This is to compare a fly to an elephant -- one can easily change the value
of any variable in C, C is an imperative language.

XSLT supports the declarative programming style -- the value of a variable
once defined cannot be modified. There is no concept of state, order of
execution, memory,... etc.

Once again, the people, who really understand best their subject matter
define XSLT as a functional language.

Furthermore, your statement that XSLT has no concept of program flow is not
entirely true. Just consider <xsl:for-each>.

The fact that the elements of the current node-list are processed by
xsl:for-each in a specific order (document order, unless this is overriden
by an xsl:sort) does not equate to "program flow" -- e.g. when processing
with xsl:for-each an element from the current node-list it is not possible
to refer to the result of processing the previously processed nodes from the
current node-list -- this is not "flow", but quite disrupted, independent
sequential processing.

Also, there is absolutely no limitation on the order in which the nodes of
the current node-list are processed by xsl:apply-templates. The results of
applying the templates to all the nodes from the current node-list are
presented according to the document order (or the order specified by
xsl:sort) *after* all elements have been processed. They may be processed in
parallel or in any order.

I believe that the same was meant for xsl:for-each, but the description in
the spec. is not precise. That is, the sentence:

"Implementations are free to process the source document in any way that
produces the same result as if it were processed using this processing
model." from http://www.w3.org/TR/xslt#section-Processing-Model probably was
meant to apply also to xsl:for-each processing.

As a rule, every XSLT programmer knows that one shouldn't rely on any order
of processing.

There are ways to simulate "program flow": by defining a dependency between
two xsl:variable s or by recursive processing and passing the necessary
values as parameters. But this is not a *concept* in the language.

I admit that you find several things that are also common in functional
languages, but on the other hand, many important things are missing IMO.

P.S: I nonetheless find your effort to define functional patterns in XSLT
very interesting and appreciate your work.

Thank you for your appreciation. I find a dialogue as this one very useful
as it contributes to bringing to many people the right understanding about
the nature, power and expressiveness of XSLT.



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Dimitre Novatchev]

You mean Haskell pattern matches would work the same if they were executed
from bottom to top? ;-}

Not at all )

The statement above is that there is no *concept* of program flow in a
functional programming language, not that there aren't ways to implement
something that looks like it. In fact, it is significantly easier to
implement sequential processing in Haskell (via monads) than in XSLT.



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Bob Foster]

Must have been temporarily down. Works ok today.

Bob

 

[Cougarkhan]

Still down.

Must have been temporarily down. Works ok today.

Bob

 

[Sebastian Schaffert]

Thank you for your opinion. I dare to give more waight to one of the best
specialists in the area of FP, Phil Wadler, who very firmly stated (a year
ago at the last Summer School in Functional Programming, in Oxford) that
XSLT is a functional language and is the most used functional language.

Probably there's just a terminological difference between you two, but
permit me to accept Phil Wadler's statement.

I accept that and I know that Phil Wadler is of that opinion. Nonetheless I
have difficulties to accept that XSLT is a functional language. One reason
is probably that the more recent functional languages like SML or Haskell
are so nice to work with and appear to be very clean. XSLT lacks all of
this beauty, IMO.

BTW, as far as I know XSLT was not designed as a functional language in the
beginning. That was attributed to it later, when the functional programming
community "found out" about XML.

He is one of the creators of another functional language -- XQuery. Once
again, XQuery is a functional language according to Wadler, although it
lacks higher order functions.

At least they will probably get static typing sometime in the future with
XQuery. XQuery is definately a step forward from XSLT, and is well suited
for many applications. But I still think that it is not the ultima ratio in
querying semistructured data, as it tends to be very complicated even for
small queries and similar queries are not at all similar in XQuery
(consider e.g. the XQuery use cases, queries XMP Q3 and Q4).

I feel sympathy for your pain. In XSLT 2.0 one can define an xsl:function
and then reference it directly in an XPath expression, without the need of
xsl:call-template. BTW, XSLT 2.0 also has static type checking.

As for feeling pain when having to use xsl:call-template recursively, I

What I meant is compare the two-liner foldl in the Haskell Prelude with the
don't-know-how-many-lines-but-over-20 foldl in XSLT.

haven't heard such an opinion in the xsl-list for almost three years. Some
people feel uncomfortable about recursion in general, but nobody has
voiced any concerns about xsl:call-templates.

Probably because so many people think that XSLT is great. Which it isn't in
my opinion. I don't criticize call-templates in particular. I criticize
XSLT as a whole, mainly because it is a difficult, non-intuitive language
even for things that ought to be easy. Maybe this is in large parts to be
attributed to XPath, but not only.

Your feelings are something relative and personal. I understand that a
programmer, having been trained in an imperative language, would be
uncomfortable with recursion.

In the same way a programmer trained in an FP language would feel very
uncomfortable having to assign new values to variables and to remember
what state is associated with which value of a variable.

Hundreds and hundreds of young people trained in an FP language (several
universities teach an FP language as a first programming language) will
feel similar pain if they are forced to use an imperative language.

You are too fast to put me into the imperative corner. In fact, I primarily
program in Haskell and among others teach functional programming to
students, so I am very comfortable with recursion.

What I am not at all comfortable with is the recursion as it is used in
XSLT, it is not descriptive enough.

This is to compare a fly to an elephant -- one can easily change the value
of any variable in C, C is an imperative language.

Admitted. I just wanted to point out that the ability to apply functional
design patterns does not necessarily make a language functional.

XSLT supports the declarative programming style -- the value of a variable
once defined cannot be modified. There is no concept of state, order of
execution, memory,... etc.

"Declarative" is a term which is very vague and very subjective. A common
definition of "declarative" is "easy to grasp because what is done is
rather obvious", (or more formal: "close to the declarative semantics") and
this is not a thing I would easily attribute to XSLT (but definately to
Haskell).

Once again, the people, who really understand best their subject matter
define XSLT as a functional language.

I accept that Philip Wadler does have a lot of knowledge regarding
functional languages. On the other hand, this doesn't hinder me from
criticizing his view on this topic.

The fact that the elements of the current node-list are processed by

[...]

I accept your explanation, it makes sense. Nonetheless there are also
control-flow-based languages that have such a "consuming" loop construct,
e.g. Python.

The criterion which is most convincing for XSLT not being an imperative
language is probably the referential transparency used for variables.
On the other hand, I still think that many of the properties that were taken
for granted in more recent functional languages (which make functional
programming beautiful and worthwhile) are missing in XSLT.

Also, as stated above, I don't consider XSLT being particularly declarative.
Probably more declarative than programming with the DOM in some imperative
lower-level language, but not close to the declarativity found in
functional languages like Haskell or SML or in logic languages like Prolog.

I also think that I am not the only one thinking in this direction. Have you
had a look at the CDuce (or XDuce) project?

http://www.cduce.org

Thank you for your appreciation. I find a dialogue as this one very useful
as it contributes to bringing to many people the right understanding about
the nature, power and expressiveness of XSLT.

I think that everyone with at least some programming skills will easily
accept that XSLT is Turing complete and thus as expressive as any
programming language can be (I have seen someone proving it using
mu-recursive functions, if there is someone who does not accept this).

However, this does (IMO) not make XSLT a language that is easy to use and
therefore well suited as a language that ought to be used by web
programmers.

 

[Dimitre Novatchev]

In your message the following main points are expressed:

1. You disagree with Phil Wadler that XSLT and XQuery are functional
languages

2. You disagree with the undisputed fact that XSLT is a declarative
language.

3. You personally find using XSLT inconvenient.


These are all personal feelings, such as every person is entitled to have.

Therefore, there's nothing to argue about someone's personal feelings, as
the purpose of a newsgroup like this one is to work with facts and to help
solve real problems.

Nor do personal feelings change the facts of reality (e.g. the real
properties of XSLT -- a functional language as defined by some of the
leading experts in functional programming, a language used by many thousands
of programmers).


Thank you once again for the interesting discussion.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

Thank you for your opinion. I dare to give more waight to one of the best
specialists in the area of FP, Phil Wadler, who very firmly stated (a year
ago at the last Summer School in Functional Programming, in Oxford) that
XSLT is a functional language and is the most used functional language.

Probably there's just a terminological difference between you two, but
permit me to accept Phil Wadler's statement.

I accept that and I know that Phil Wadler is of that opinion. Nonetheless I
have difficulties to accept that XSLT is a functional language. One reason
is probably that the more recent functional languages like SML or Haskell
are so nice to work with and appear to be very clean. XSLT lacks all of
this beauty, IMO.

BTW, as far as I know XSLT was not designed as a functional language in the
beginning. That was attributed to it later, when the functional programming
community "found out" about XML.

He is one of the creators of another functional language -- XQuery. Once
again, XQuery is a functional language according to Wadler, although it
lacks higher order functions.

At least they will probably get static typing sometime in the future with
XQuery. XQuery is definately a step forward from XSLT, and is well suited
for many applications. But I still think that it is not the ultima ratio in
querying semistructured data, as it tends to be very complicated even for
small queries and similar queries are not at all similar in XQuery
(consider e.g. the XQuery use cases, queries XMP Q3 and Q4).

I feel sympathy for your pain. In XSLT 2.0 one can define an xsl:function
and then reference it directly in an XPath expression, without the need of
xsl:call-template. BTW, XSLT 2.0 also has static type checking.

As for feeling pain when having to use xsl:call-template recursively, I

What I meant is compare the two-liner foldl in the Haskell Prelude with the
don't-know-how-many-lines-but-over-20 foldl in XSLT.

haven't heard such an opinion in the xsl-list for almost three years. Some
people feel uncomfortable about recursion in general, but nobody has
voiced any concerns about xsl:call-templates.

Probably because so many people think that XSLT is great. Which it isn't in
my opinion. I don't criticize call-templates in particular. I criticize
XSLT as a whole, mainly because it is a difficult, non-intuitive language
even for things that ought to be easy. Maybe this is in large parts to be
attributed to XPath, but not only.

Your feelings are something relative and personal. I understand that a
programmer, having been trained in an imperative language, would be
uncomfortable with recursion.

In the same way a programmer trained in an FP language would feel very
uncomfortable having to assign new values to variables and to remember
what state is associated with which value of a variable.

Hundreds and hundreds of young people trained in an FP language (several
universities teach an FP language as a first programming language) will
feel similar pain if they are forced to use an imperative language.

You are too fast to put me into the imperative corner. In fact, I primarily
program in Haskell and among others teach functional programming to
students, so I am very comfortable with recursion.

What I am not at all comfortable with is the recursion as it is used in
XSLT, it is not descriptive enough.

This is to compare a fly to an elephant -- one can easily change the value
of any variable in C, C is an imperative language.

Admitted. I just wanted to point out that the ability to apply functional
design patterns does not necessarily make a language functional.

XSLT supports the declarative programming style -- the value of a variable
once defined cannot be modified. There is no concept of state, order of
execution, memory,... etc.

"Declarative" is a term which is very vague and very subjective. A common
definition of "declarative" is "easy to grasp because what is done is
rather obvious", (or more formal: "close to the declarative semantics") and
this is not a thing I would easily attribute to XSLT (but definately to
Haskell).

Once again, the people, who really understand best their subject matter
define XSLT as a functional language.

I accept that Philip Wadler does have a lot of knowledge regarding
functional languages. On the other hand, this doesn't hinder me from
criticizing his view on this topic.

The fact that the elements of the current node-list are processed by

[...]

I accept your explanation, it makes sense. Nonetheless there are also
control-flow-based languages that have such a "consuming" loop construct,
e.g. Python.

The criterion which is most convincing for XSLT not being an imperative
language is probably the referential transparency used for variables.
On the other hand, I still think that many of the properties that were taken
for granted in more recent functional languages (which make functional
programming beautiful and worthwhile) are missing in XSLT.

Also, as stated above, I don't consider XSLT being particularly declarative.
Probably more declarative than programming with the DOM in some imperative
lower-level language, but not close to the declarativity found in
functional languages like Haskell or SML or in logic languages like Prolog.

I also think that I am not the only one thinking in this direction. Have you
had a look at the CDuce (or XDuce) project?

http://www.cduce.org

Thank you for your appreciation. I find a dialogue as this one very useful
as it contributes to bringing to many people the right understanding about
the nature, power and expressiveness of XSLT.

I think that everyone with at least some programming skills will easily
accept that XSLT is Turing complete and thus as expressive as any
programming language can be (I have seen someone proving it using
mu-recursive functions, if there is someone who does not accept this).

However, this does (IMO) not make XSLT a language that is easy to use and
therefore well suited as a language that ought to be used by web
programmers.



--
Sebastian

PGP Key fingerprint =
13 1D 2E 4F 20 3E C9 1F 4C 57 52 87 8A 80 48 4D F5 E9 97 EC

 

[Bob Foster]

In your message the following main points are expressed:

1. You disagree with Phil Wadler that XSLT and XQuery are functional
languages

2. You disagree with the undisputed fact that XSLT is a declarative
language.

3. You personally find using XSLT inconvenient.

These are all personal feelings, such as every person is entitled to have.

Therefore, there's nothing to argue about someone's personal feelings, as
the purpose of a newsgroup like this one is to work with facts and to help
solve real problems.

Nor do personal feelings change the facts of reality (e.g. the real
properties of XSLT -- a functional language as defined by some of the
leading experts in functional programming, a language used by many thousands
of programmers).

Thank you once again for the interesting discussion.

I think that gives short shrift to what I see as Sebastian's main objection
to XSLT - he doesn't find it beautiful. Apparently he does find Haskell and
SML so. Beauty is a perfectly respectable word in mathematics and should be
in programming. The recognition of beauty and elegance is more than just a
"personal feeling", it is a quality of mind that all practitioners should
strive for. The purpose of a newsgroup is to exchange information, and the
fact that some people find XSLT unlovely is certainly information.

However, as a newsgroup topic it has two main problems. First, it is
something of a dead horse. XSLT could possibly be beautiful if it had a
syntax to match the elegance of its ideas, but it does not and no one seems
to be proposing such a thing, perhaps because, cumbersome as it is, the
notation happens to suit the problems it solves. Certainly, a more beautiful
language with the same properties would be interesting, but without an
alternative, the conversation can't go far.

Second, XSLT does have an inner beauty that people who take the time to get
past its facade come to appreciate. It is also surprisingly strong, and has
more intelligence than is first apparent. (Certainly, you have coaxed it to
do things I would not have imagined it could.) So perhaps a more mature
appraisel is that it might not be one's first choice for romance but makes
an excellent spouse. ;-}

Bob Foster