Re: [Exist-development] New list member offering services :)

[Thomas W. <tho...@gm...>]

Tony,

Asking about what is better XQuery or XSLT is like asking which car is
better Ferrari or Bentley. The answer is: "It depends"!  What are you
looking for, how are going to use it, who are you going to use it with etc.

To me XSLT and XQuery in the XML world are like the left and the right hand
- some tasks are better, quicker and easier to reach when implemented with
XSLT and other are better, quicker and esier when written in XQuery. There
is never a simple "right" answer. Are you are writing one off
transformation? How often you are going to change it and the most important
question - which of these languages comes more natural to you and makes you
more productive.

I used to write almost everything in XSLT using XQiery just as a glue layer
between the requests, the database and the XSLT. Recently because of time
constraints I switched to XQuery completely and I am very pleased with the
quick results. I still use XSLT here and there and I am convinced XSLT is a
place to lay very good foundations for XQuery.

I think one of strengths of XSLT is its simple mechanism for extensibility
when using pattern matching. All you need to do is to add an include file
with additional pattens and you are done. You can repeat this as many times
as you need without ever changing the original XSLT file. You can even
generate a list of include files as you need them, even in run time. XSLT is
perfect for creating highly reusable libraries.

Using the typeswitch in XQuery  is completely the opposite. The only way to
extend the original functionality is to add MANUALLY all new cases into the
ORIGINAL file. When we work with predictable, stable, slow changing data,
like documentation XQuery it perfectly OK. But if you do data driven
applications there the code adapts to the data then XQuery is still behind
XSLT. Having said that I have to add that using util:function and util:call
can find same way around and mimic the XSLT way. My point is the
extensibility in XQuery does not come out of the box as with XSLT.

Switching same functionality from one language to another could be very
educational and brings a lot of fun. If somebody wants to toy with it and
there is a need I say why not, go for it. There is always room to make
things better, faster and easier to maintain.

I hope this helps.

Thomas


------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



On 9 April 2010 21:30, Wolfgang Meier <wol...@ex...> wrote:

> > I dont think that doing basic document to document conversion in
> > XQuery makes any sense, XSLT is easier to develop this in and more
> > intuitive.
>
> I think this is a misunderstanding. A simple document to document
> transformation can sometimes be even more intuitive in XQuery ;-) All
> you need to learn is typeswitch plus a few function calls. I'm using
> this more and more in my own code (for example, see
>
> http://exist.svn.sourceforge.net/viewvc/exist/trunk/eXist/webapp/biblio/jquery.xql?revision=11607&view=markup
> ).
> Done in the right way, the control flow in an XQuery can be easier to
> understand and maintain than the template matching mechanism of XSLT.
>
> Don't misunderstand me. I like XSLT. I use a pretty large XSLT to
> generate multi-volume, 1000 pages PDFs from a set of TEI documents
> stored in eXist. The processing only takes a few minutes, despite the
> thousands of small queries it sends to eXist, e.g. to assemble
> bibliographies and SVG graphics. However, this also shows the
> limitations of XSLT: it becomes quite tricky once you need to
> integrate data from many sources. Native XSLT support in eXist would
> overcome this limit. It's on the way, but there's still a lot of work
> left to be done.
>
> Anyway, my main argument for using more XQuery for the website is that
> you want to keep the examples as simple as possible and reduce the
> number of standards new users have to learn.
>
> Wolfgang
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>