Future of XSLT? [was: Very Interesting]

Article:
What Is XQuery

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

Date: 2003-01-22 22:44:27

From: Per Bothner

Response to: Future of XSLT? [was: Very Interesting]

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

Previous Message Up Next Message

Titles Only

Newest First

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