Article:		Processing RSS
Subject:		XQuery and XSLT
Date:		2003-04-18 21:40:44
From:		Per Bothner
Response to: XQuery and XSLT
> 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.

Previous Message

Up

Next Message

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