Sign In/My Account | View Cart  
advertisement

Article:
 Comparing XSLT and XQuery
Subject: Off Target
Date: 2005-03-10 23:29:34
From: dnovatchev

> XSLT is to XQuery as JavaScript is to Java.
> XSLT is untyped; conversions between nodes and
> strings and numbers are handled pretty much
> transparently.


Simply not true. Both XQuery and XSLT 2.0 use the same common subset expression language (XPath 2.0) and its data model. Both are typed. While both have approximately the same power, there are tasks, which are more easily accomplished using XSLT 2.0.


This article would have been more useful were it written in 2001.


What is strange is that XSLT 1.0 (yes, the author does not specify what he means by "XSLT") is compared to XQuery.


Why should someone compare two products using the 1999 version of the first and the 2005 working draft of the second?


I would definitely *not* recommend this article as an authoritative text on the subject.


This time xml.com wasn't too-useful either...


Best regards,
Dimitre Novatchev


Previous Message Previous Message   Next Message Next Message


Titles Only Titles Only Newest First
  • Off Target
    2005-03-11 16:13:14 J David Eisenberg

    I should get an award for "worst. simile. ever." Let me put it this way: XSLT (any version) does have an underlying type system, but your XSLT stylesheet doesn't have to specify the datatype of everything; you can even skip the as="" attribute on xsl:param if you so desire. XSLT tends to handle string/number/node-to-text conversions without a lot of fuss--it almost always delivers a reasonable result, even if it's not what you'd ideally like. XQuery tends to be more vocal if you don't specify types. I'm not saying that one way is "better" or "worse" - that depends on your philosophy and the task at hand.


    But yeah, that simile was really awful.




    • Off Target
      2005-03-11 20:35:09 dnovatchev

      > Let me put it this way:


      > XSLT (any version) does have an underlying
      > type system, but your XSLT stylesheet doesn't
      > have to specify the datatype of everything;
      > you can even skip the as="" attribute on
      > xsl:param if you so desire. XSLT tends to
      > handle string/number/node-to-text conversions
      > without a lot of fuss--it almost always
      > delivers a reasonable result, even if it's not
      > what you'd ideally like.


      Quite *not* so. I don't think anyone who has actually written XSLT 2.0 code will make the quoted statement.


      XSLT 2.0 uses XPath 2.0 which has stringent type-checking rules.


      For example, even something as simple as the following transformation raises type errors, as evidenced using Saxon 8.3B:


      <xsl:stylesheet version="2.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      >

      <xsl:template match="/">
      <xsl:copy-of select="*/*
      [3 < substring(@n,2)]"/>
      </xsl:template>
      </xsl:stylesheet>


      when applied on this source xml document:


      <t>
      <x n="n1"/>
      <x n="n2"/>
      <x n="n3"/>
      <x n="n4"/>
      <x n="n5"/>
      </t>


      the result is:


      Saxon 8.3 from Saxonica
      Java version 1.5.0_01
      Error at xsl:copy-of on line 6 of file:/C:/Program%20Files/Java/jdk1.5.0_01/bin/marrowtr.xsl:
      XP0006: Cannot compare xs:integer to xs:string
      Failed to compile stylesheet. 1 error detected.



      Best regards,
      Dimitre Novatchev.

      • Off Target
        2005-03-11 21:58:12 J David Eisenberg

        A quick further note: I also have been testing some XSLT files I wrote for transforming XML to OpenOffice.org files; I just changed the version to 2.0 and everything continued to work. I guess I was unlucky enough to write transformations that didn't hit any of the type problems.

        • Off Target
          2005-03-11 22:23:59 dnovatchev

          Yes, this may happen and is indeed a question of luck.


          Specifying version="1.0" causes the XSLT processor to work in "backwards compatibility mode" but even in this case the XSLT processor uses the XPath 2.0 data model -- therefore it does not completely behave as an XSLT 1.0 processor.


          Best regards,
          Dimitre Novatchev

      • Off Target
        2005-03-11 21:15:58 J David Eisenberg

        You're right; my experience with 2.0 is fairly limited, and that's what I get for running a test transformation in Saxon without changing the version from 1.0 to 2.0.

      • Off Target
        2005-03-11 20:40:13 dnovatchev

        I wrote:


        <xsl:copy-of select="*/*
        [3 < substring(@n,2)]"/>
        </xsl:template>


        Of course, the "less-than" operator was written escaped, however it is displayed as"<" -- I just don't know how to enter xslt code so that it would be properly displayed on this site -- anyway, the example is very simple and must be clear.


        Dimitre Novatchev

  • Off Target
    2005-03-11 05:26:25 bryan rasmussen

    if we're gonna get a language war going I think XSLT 1.0 is still preferable to XQuery 1.0


    whenever XQuery 1.0 comes through.





Sponsored By: