Future of XSLT? [was: Very Interesting]

Article:
What Is XQuery

Subject: Future of XSLT? [was: Very Interesting]

Date: 2002-10-18 09:00:35

From: Per Bothner

Response to: Very Interesting

> Why is the W3C body allowing 2 directly competing standards to emerge together?

I guess because there is a need for XQuery, as it is usable for applications where XSLT is very unsuitable, and XSLT is already well-established. In any case, they use two very different approaches, and there is nothing wrong with allowing multiple alternatives.

> Are there XQuery examples for bigger programs which require packaging, organizing different files, etc.

No, this kind of modularization is a weak area in the current drafts = and a strength of XSLT.

> Very good article

Thanks! At least one more (which emphasizes the XSLT target area of generating XML/HTML) will appear on xml.com in the near future.

Previous Message Up Next Message

Titles Only

Newest First

Future of XSLT? [was: Very Interesting]
2002-10-21 23:37:24 Brandon Ibach [Reply]

> I guess because there is a need for XQuery, as
> it is usable for applications where XSLT is
> very unsuitable

An intriguing statement... Examples?
- Future of XSLT? [was: Very Interesting]
  2002-10-24 11:17:25 Per Bothner [Reply]
  
  XSLT is designed for reading a single input file and generating a single output file. There are extensions for multiple input and output files, but the basic model is one-to-one. If you need to merge multiple documents, for example, then XSLT is difficult.
  
  Furthmore, XSLT is very awkward for any kind of real programming. Defining and calling functions is very awkard and tedious. The syntax is very verbose, hence the escape into the much more compact XPath. One might say that XQuery is XPath extended into a full programming language.
  - Future of XSLT? [was: Very Interesting]
    2003-01-06 17:37:12 Brandon Ibach [Reply]
    
    > XSLT is designed for reading a single input file
    > and generating a single output file. There are
    > extensions for multiple input and output files,
    > but the basic model is one-to-one. If you need
    > to merge multiple documents, for example, then
    > XSLT is difficult.
    
    I've not found it difficult. The document() function has existed in XSLT all along, and you seem to use it in your XQuery examples, as well. How is XQuery so different in this regard?
    
    As for multiple output documents, it appears (from what I've seen in your articles, I'm not well versed on the current state of the standard) that XQuery has no standardized method. XSLT 1.0 didn't, either, although most implementations ended up providing a similar mechanism, which is being standardized in XSLT 2.0.
    > Furthmore, XSLT is very awkward for any kind of
    > real programming. Defining and calling
    > functions is very awkard and tedious. The
    > syntax is very verbose, hence the escape into
    > the much more compact XPath. One might say that
    > XQuery is XPath extended into a full programming
    > language.
    
    Granted, XSLT is rather verbose, but that is the nature of XML. SGML had a number of (IMHO) slick methods for cutting down on markup characters, but these were discarded in the design of XML, for simplicity.
    
    I think XPath in XSLT is a nice compromise between compactness and rich structure. However, XQuery has essentially dove to one end, abandoning XML-based structure entirely just for compactness. XSLT is getting some improvements in this area with XSLT 2.0, in that it allows for defining new XPath functions using XSLT and XPath, in a standardized way (again, similar to proprietary implementations that have existed for a while).
    
    In the end, I fail to see what XQuery provides, other than a less structured, more compact syntax for the things I do now in XSLT, but minus the built-in template processing model, and with no apparent basis for the kind of extensibility that XSLT has allowed.
    
    Please don't think I'm just here to flame XQuery. I really am trying to evaluate the technology, and understand the motives and intents behind its design.
    - Future of XSLT? [was: Very Interesting]
      2003-01-22 22:44:27 Per Bothner [Reply]
      
      >> If you need yo merge multiple documents,
      >> for example, then XSLT is difficult.
      
      > I've not found it difficult. The document()
      > function has existed in XSLT all along, and you
      > seem to use it in your XQuery examples, as well.
      
      However you cannot pass the result from document
      through the XSLT template processor. You can
      insert the result in the output - anything else
      is quite tedious.
      
      > How is XQuery so different in this regard?
      
      The difference is that that XQuery allows
      element construction, document input, and
      node selection/extraction to be combined
      and nested much more flexibly.
      
      > However, XQuery has essentially dove to one end, > abandoning XML-based structure entirely just for > compactness.
      
      Compactness is an important value in a programming
      language. Programming errors tend to be
      proportional to program length, and productivity
      as measured in tokens per programmer-day seems
      to be relatively language-independent. So
      compactness is valuable. (My impression is
      that number of tokens is more important than
      number of characters, so perhaps APL and Perl
      go too far. Note this is just what I vaguely
      remember reading - I don't have references.)
      
      While XML is a good syntax for documents and
      data, it is (I think) a terrible syntax for a
      programming language.
      - Future of XSLT? [was: Very Interesting]
        2003-02-21 12:43:32 Brandon Ibach [Reply]
        
        > However you cannot pass the result from document
        > through the XSLT template processor. You can
        > insert the result in the output - anything else
        > is quite tedious.
        
        Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of anything in the XPath 1.0 or XSLT 1.0 specs that prevents this. Please correct me if I'm mistaken on this.
        
        > The difference is that that XQuery allows
        > element construction, document input, and
        > node selection/extraction to be combined
        > and nested much more flexibly.
        
        This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly? Again, examples of use cases (or pointers to them) where XQuery provides a significantly easier or more efficient solution than XSLT would clarify your point.
        
        > Compactness is an important value in a
        > programming language. Programming errors tend
        > to be proportional to program length, and
        > productivity as measured in tokens per
        > programmer-day seems to be relatively
        > language-independent.
        > While XML is a good syntax for documents and
        > data, it is (I think) a terrible syntax for a
        > programming language.
        
        Agreed. Every attempt to create a programming language based on XML syntax has either been too awkward to use or has invented some "alterations" to XML to make it more usuable, such that it really isn't XML anymore. In a way, XSLT falls into the latter category. A good bit of the logic in XSLT is expressed in XPath, which uses a non-XML syntax. As seen in the XPath 2.0 and XSLT 2.0 drafts, even more power is being put into XPath. As I've said, I think there's a good balance there, so it satisfies both the compact-syntax-desiring programmer in me and the markup fanatic in me. Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it really is from my favorite scripting language with a good XPath library.
        
        One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements that will be coming with XSLT 2.0? Given that XQuery uses XPath 2.0, and thus benefits from lessons learned with XPath 1.0 and XSLT 1.0, it would hardly be fair to compare to the older standards.
        
        [ Side note: Does xml.com have some way to get notified when someone replies to your post? This discussion is getting drawn out quite a bit as I keep forgetting to check back for responses. ]
        
        Future of XSLT? [was: Very Interesting]
        2003-02-21 17:30:47 Per Bothner [Reply]
        
        > Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of
        > anything in the XPath 1.0 or XSLT 1.0 specs that prevents this.
        
        Perhaps we're talking about different things. Could you give an example of how you do this?
        
        > This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly?
        
        XQuery allows you to nest element constructor expressions (XML syntax) inside complex XQuery expressions, and you can conversely nest complex
        XQuery expressions inside element constructors.
        With XSLT, you can nest XPath expressions inside
        XML, but you can't nest XML constructors inside
        XPath expressions. So a loop or recursive
        function that returns new XML nodes is difficult
        to write.
        
        > Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it
        > really is from my favorite scripting language with a good XPath library.
        
        The big difference is how easy it is to *create*
        XML nodes using XQuery, and then process them
        just like nodes from an input document.
        With e.g. JSP you create *text*, not *nodes*.
        See my later article:
        http://www.xml.com/pub/a/2002/12/23/xquery.html
        
        > One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements
        > that will be coming with XSLT 2.0?
        
        I'm trying to, though I don't have as good a picture of XSLT 2.0.
        
        > Side note: Does xml.com have some way to get notified when someone replies to your post? This
        > discussion is getting drawn out quite a bit as I keep forgetting to check back for responses.
        
        I know I as an author get notification, but I
        don't know if you can request it.
        
        Future of XSLT? [was: Very Interesting]
        2003-03-06 06:35:10 Brandon Ibach [Reply]
        
        > > Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of
        > > anything in the XPath 1.0 or XSLT 1.0 specs that prevents this.
        > Perhaps we're talking about different things. Could you give an example of how you do this?
        
        Certainly. :)
        
        <xsl:template match="order">
        
        <xsl:for-each select="item">
        <xsl:apply-templates select="document('products.xml')//product[@id = current()/@ref]">
        <xsl:with-param name="item" select="."/>
        </xsl:apply-templates>
        </xsl:for-each>
        </xsl:template>
        
        <xsl:template match="product">
        <xsl:param name="item"/>
        
        </xsl:template>
        
        This, of course, is just one way in which this sort of thing can be done. Is this what you had in mind?
        
        > > This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly?
        
        > XQuery allows you to nest element constructor expressions (XML syntax) inside complex XQuery expressions, and you can conversely nest complex
        > XQuery expressions inside element constructors.
        > With XSLT, you can nest XPath expressions inside
        > XML, but you can't nest XML constructors inside
        > XPath expressions. So a loop or recursive
        > function that returns new XML nodes is difficult
        > to write.
        
        It is possible to set a variable to a result tree fragment, then use that variable in another XPath expression, though you're right that it can't be done directly, and RTFs are a pain to work with, anyway, due to the restrictions on them.
        However, RTFs go away with XSLT 2, and everything is a node set, so generating XML nodes that can be used just as if they came from an input document will be easier. Also, the addition of standard support for XPath extension functions defined in XSLT will provide another flexible way to do this.
        As for loops and recursive functions, I create these regularly using <xsl:call-template>. The syntax does make it a little awkward, but not unreasonable, and this will also get easier with the new extension function support in XSLT 2.
        
        > > Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it
        > > really is from my favorite scripting language with a good XPath library.
        
        > The big difference is how easy it is to *create*
        > XML nodes using XQuery, and then process them
        > just like nodes from an input document.
        > With e.g. JSP you create *text*, not *nodes*.
        
        I suppose I can see that. Offhand, I can't think of an example of where this would be important to me, but maybe I just don't have the right kind of application in mind. *shrug*
        
        > > One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements
        > > that will be coming with XSLT 2.0?
        
        > I'm trying to, though I don't have as good a picture of XSLT 2.0.
        
        The current draft spec seems to outline the changes fairly well. I think the most important aspects, at least for this discussion, are the improvements in XPath 2.0, with which you must be quite familiar, the elimination of result tree fragments and the standardization of XPath extension functions written in XSLT.
        
        I'm still eager to see some examples that show how XQuery can solve the same problem better than XSLT. Can you point me to something like this? I really am interested in the possibility of applying XQuery in my own work, but haven't found the compelling reason to use it over XSLT.
        
        Future of XSLT? [was: Very Interesting]
        2003-03-15 23:15:19 Per Bothner [Reply]
        
        > <xsl:apply-templates select="document('products.xml')//product[@id = current()/@ref]">
        
        The XSLT 2.0 draft spec 6.2 says "The xsl:apply-templates instruction takes as input a sequence of nodes in the source tree". One could argue that prohibits your usage, since the nodes aren't in the "source tree". But I think it's
        just a poor choice - I agree it *should* be allowed.
        
        The main advantage of XQuery is that everything
        nests. You can iterate over one of more
        data-sets (i.e. a join), construct elements
        containg arbirary expressions based on each
        value of the "loop", and pass arbitary data
        as arguments and results of user-defined functions. I don't offhand know if there is
        a set of XQuery programs you can't express
        in XSLT, but think many of them will be a lot
        more natural and compact using XQuery.
        
        For now we'll just have to disagree, at least
        until there is more experience with XQuery, or
        I read a good analysis of their relative "power".
        
        >The big difference is how easy it is to *create*
        >> XML nodes using XQuery, and then process them
        >> just like nodes from an input document.
        >> With e.g. JSP you create *text*, not *nodes*.
        
        > I suppose I can see that. Offhand, I can't think of an example of where this would be important to
        > me, but maybe I just don't have the right kind of application in mind.
        
        Think of filters, where you're passing data from
        one transformation to another. If the data are
        nodes rather than text, not only can you express
        a transformation chain very compactly and
        naturally as a set of function calls, but it
        also should be more efficient than continuously
        formatting and parsing the data.
        
        > I'm still eager to see some examples that show how XQuery can solve the same problem better than
        > XSLT. Can you point me to something like this? I really am interested in the possibility of
        > applying XQuery in my own work, but haven't found the compelling reason to use it over XSLT.
        
        Well, perhaps for you, who are fluent in XSLT,it's not that compelling. But I'd be curious to see
        how you'd the photo album application. See
        http://xml.com/pub/a/2002/12/23/xquery.html
        - the latest version version of the XQuery source is
        http://www.gnu.org/software/qexo/qalbum/pictures.xql
        and an example showing most of the features is
        http://pics.bothner.com/2002/BristleconePines/ .)