Article:		Processing RSS
Subject:		XQuery and XSLT
Date:		2003-04-12 08:17:13
From:		Michael Champion
As best I understand it, and for situations that don't involve XQuery's deeper support for XML Schema data types, XQuery and XSLT are more or less equivalent in functionality. I believe that all the use cases in the XQuery specification can be implemented with either. So why are both needed? Not everyone would agree that they are, and both are (AFAIK) Turing-complete programming languages. The best explanation I can offer is that each is optimized for the needs of different audiences. XSLT tends to be somewhat easier for document-oriented applications, XQuery somewhat easier for data-oriented applications, especially by those coming from a SQL background and those who need a "native XML programming language" rather than a "template-driven XML transformation" tool.

Previous Message

Next Message

• XQuery and XSLT
  2003-10-19 03:33:26 Dimitre Novatchev [Reply]
  
  > One way to think of them: XSLT is essentially a > special-purpose scripting language. It is
  > designed to be interpreted, and there is no
  > static type-checking or optimization.

  
  Speking about XSLT 2.0 almost everything in the above statement is quite wrong:

  
  - there *is* static type checking.

  
  - there is optimization performed even in most
  XSLT 1.0 processors.

  
  
  > XQuery aspires to be a real general-purpose
  > programming language, albeit one with syntax
  > and data types optimized for XML applications.
  > It supports (at least optionally) type-
  > checking, optimization, and compilation.

  
  So you imply that XSLT is not so real general-purpose programming language than XQuery?

  
  Of course this is not true -- XSLT 2.0 has all major features that XQuery has.

  
  What XQuery doesn't offer and what happens to be one of the most powerful features of XSLT is the mechanism to apply the best-matching template out of many.

  
  There are great consequences from this -- e.g. it is possible to implement higher order functions and functional programming in XSLT (see the FXSL library), while this does not seem possible to be done with XQuery.

  
  Dimitre Novatchev

  
  
  
  

• XQuery and XSLT
  2003-04-18 21:40:44 Per Bothner [Reply]
  
  > So why are both needed?

  
  One way to think of them: XSLT is essentially a special-purpose scripting language. It is designed to be interpreted, and there is no static type-checking or optimization. XQuery aspires to be a real general-purpose programming language, albeit one with syntax and data types optimized for XML applications. It supports (at least optionally) type-checking, optimization, and compilation.

  
  This is of course a gray boundary. It is possible to compile and statically analyze at least a subset of XSLT, and it is possible to do quick-and-dirty scripting in XQuery. But your point about "deeper support for XML Schema data types" goes beyond Schema: Having a statically analyzable syntax and type system allows you to catch type errors as compile-time errors rather than run-time errors which I think is very valuable.
  
  

  • XQuery and XSLT
    2003-04-19 13:13:25 Oleg Tkachenko [Reply]
    
    Come on, XSLT is not a "special-purpose scripting language", it's turing complete functional language, look at FXSL library as a prominent example.
    And XSLT is designed to allow compiation, that's why xsl:include cannot be dynamic and there is no dynamic XPath evaluatuion even in XSLT2. Moreover, *all* XSLT processors I'm aware do compile XSLT stylesheets and do optimize from //* stuff to tail recursion, that's all pretty possible even in XSLT1.0.
    XQuery and XSLT2 really look extremelly similar, except for syntax, but does syntax matter?
    "XQuery is XSLT with no templates" (c)Jeni Tennison probably.
    
    
    • XQuery and XSLT
      2003-04-21 19:24:20 Per Bothner [Reply]
      
      > Come on, XSLT is not a "special-purpose scripting language", it's turing complete functional language,

      
      What makes you think there is any conflict between these two statements? It is very difficult *not* to be Turing complete.

      
      > And XSLT is designed to allow compiation, that's why xsl:include cannot be dynamic and there is no dynamic XPath evaluatuion even in XSLT2.

      
      People often talk about "compiled languages" vs "interpreted languages" which is of course nonsense: You can only talk about compiled vs
      interrpeted implementations. However, there is a diffence is the "mid-set" and culture of programming languages, and what kind of implementation they facilitate - and what kind of implementation people expect. Many "interpreted" languages" do at least some minimal level of compilation. One important practical difference with "compiled languages" is that people expect a compilation step, and to get static errors at compile time. But this is more a matter of culture than a hard-and-fast definition, as people can run valiators and error-checkers on a "script" as well as on a "program".

      
      > Moreover, *all* XSLT processors I'm aware do compile XSLT stylesheets and do optimize from //* stuff to tail recursion, that's all pretty possible even in XSLT1.0.

      
      I know very little about this. I would expect most implementations to "compile" to some internal form, like a special-purpose bytecode. Is it common to compile to a general-purpose bytecode (such as Java or .net CIL), or native code? (I've actually done a little work compiling XSLT to Java bytecodes, though its too incomplete to be very useful.)

      
      > XQuery and XSLT2 really look extremelly similar, except for syntax, but does syntax matter?

      
      Syntax matters a lot. If you don't think syntax matters, then you shouldn't believe XML matters, since XML is little more than a standard syntax for data. Some syntaxes are more convenient to write, easier to read, and easier to detect errors in than others. Programmer productivity varies inveresely with how many tokens are needed to express common tasks, and that is partly a matter of syntax. XSLT except for XPath is of course very verbose. Plus there is the inconsistency between the XPath syntax/world and the XML syntax/world; XQuery doesn't have this divide.

      
      > "XQuery is XSLT with no templates" (c)Jeni Tennison probably.

      
      Templates are basically just functions, which XQuery has. What XQuery doesn't have is the template *engine* - i.e. apply-templates.