Whats so great about xsl anyway? :-)

Discussion in 'XML' started by Simon Harvey, Jul 23, 2003.

  1. Simon Harvey

    Simon Harvey Guest

    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
    Simon Harvey, Jul 23, 2003
    #1
    1. Advertising

  2. Simon Harvey

    Chris Barber Guest

    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.

    "Simon Harvey" <sh856531@microsofts_free_emal_service.com> wrote in message
    news:v3zTa.49538$9.net...
    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, Jul 24, 2003
    #2
    1. Advertising

  3. > 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
    Dimitre Novatchev, Jul 24, 2003
    #3
  4. Simon Harvey

    Simon Harvey Guest

    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, Jul 24, 2003
    #4
  5. Simon Harvey

    Simon Harvey Guest

    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, Jul 24, 2003
    #5
  6. Simon Harvey

    Chris Barber Guest

    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.

    "Simon Harvey" <sh856531@microsofts_free_emal_service.com> wrote in message
    news:g9QTa.51615$9.net...
    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, Jul 24, 2003
    #6
  7. Simon Harvey

    Simon Harvey Guest

    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
    Simon Harvey, Jul 24, 2003
    #7
  8. Simon Harvey wrote:

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


    --
    Sebastian

    PGP Key fingerprint =
    13 1D 2E 4F 20 3E C9 1F 4C 57 52 87 8A 80 48 4D F5 E9 97 EC
    Sebastian Schaffert, Jul 25, 2003
    #8
  9. Simon Harvey

    Bob Foster Guest

    "Sebastian Schaffert" <> wrote in message
    news:bfrcf8$cnk$-muenchen.de...
    > 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
    Bob Foster, Jul 25, 2003
    #9
  10. > 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, Jul 25, 2003
    #10
  11. "Bob Foster" <> wrote in message
    news:6SdUa.146097$H17.51317@sccrnsc02...
    > "Dimitre Novatchev" <> wrote in message
    > news:...
    > > There's simply no concept of "program flow" in a functional
    > > programming language if by "program flow" you mean order of execution.

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


    Not at all :eek:)

    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
    Dimitre Novatchev, Jul 25, 2003
    #11
  12. Simon Harvey

    Bob Foster Guest

    Must have been temporarily down. Works ok today.

    Bob

    "Bob Foster" <> wrote in message
    news:%2eUa.144463$ye4.100130@sccrnsc01...
    > "Sebastian Schaffert" <> wrote in message
    > news:bfrcf8$cnk$-muenchen.de...
    > > 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
    >
    >
    Bob Foster, Jul 26, 2003
    #12
  13. Simon Harvey

    Cougarkhan Guest

    Still down. :)

    Bob Foster wrote:
    > Must have been temporarily down. Works ok today.
    >
    > Bob
    >
    > "Bob Foster" <> wrote in message
    > news:%2eUa.144463$ye4.100130@sccrnsc01...
    >
    >>"Sebastian Schaffert" <> wrote in message
    >>news:bfrcf8$cnk$-muenchen.de...
    >>
    >>>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
    >>
    >>

    >
    >
    >
    Cougarkhan, Jul 26, 2003
    #13
  14. Dimitre Novatchev wrote:

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


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


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


    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.

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


    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.

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

    [...]

    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


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


    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
    Sebastian Schaffert, Jul 28, 2003
    #14
  15. 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


    "Sebastian Schaffert" <> wrote in message
    news:bg41dn$udo$-muenchen.de...
    > Dimitre Novatchev wrote:
    >
    > >> 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.

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

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

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

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

    >
    > 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
    >
    Dimitre Novatchev, Jul 29, 2003
    #15
  16. Simon Harvey

    Bob Foster Guest

    "Dimitre Novatchev" <> wrote in message
    news:bg4u0n$k90b1$-berlin.de...
    > 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
    Bob Foster, Jul 30, 2003
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mdb
    Replies:
    3
    Views:
    4,165
    =?Utf-8?B?TmVpbA==?=
    Sep 20, 2004
  2. =?Utf-8?B?TmVpbA==?=
    Replies:
    1
    Views:
    666
    Mark Newby
    Apr 27, 2005
  3. Replies:
    2
    Views:
    5,350
    Scotty
    Aug 6, 2004
  4. Replies:
    1
    Views:
    3,598
    A. Bolmarcich
    May 27, 2005
  5. Eric I.
    Replies:
    0
    Views:
    250
    Eric I.
    Oct 5, 2008
Loading...

Share This Page