On Tue, Dec 2, 2008 at 3:55 PM, Robert Koberg <rob@k...> wrote:
>>>> * how to use XSL transformations from within XQuery
>>>
>>> very clumsily if you are using an XML DB, losing the advantage that you
>>> gain
>>> by the XML DB
>>
>> w/o functional idioms then yes I agree, but once funcs are first class
>> then all that awkwardness goes away.
>>
>> please expand ?
>
> In an XML DB, XQuery can operate natively on the whole database without
> creating some DOM structure in memory. When you use XSL with an XML DB, you
> have to create some source DOM in memory to feed the transform. (There is
> some work being done in eXist to allow XSL to run natively on it - don't
> have the link...)

ah yes good point, but I think u will find this is a performance
limitation rather then a conceptual limitation ... I have found that
over the years perf is becoming less and less of an issue with xml
technologies; perhaps this is hardware fault ... perhaps its the
maturity of xmldb impl (look at marklogic to get seriously impressed
from a perf pov).

>>
>>
>>>> * where to find such functional extensions
>>>> ?
>>>
>>> You *get* to make/maintain different XQuery templates for each processor
>>> you
>>> want to try out/use.
>>
>>
>> I agree that we need the equiv of EXSLT for XQuery quick ...
>> functional sigs are all different everywhere and all this is just
>> vendor lockin in a new disguise.
>
> Yep, even the same functions - eval for example - require you to basically
> maintain a different (set of) XQuery for each processor. There is no way to
> test if there is a 'function-available' or the like.

yes, I completely understand and agree that it is frustrating but its
not a fatal flaw.

>>> XQuery - the thinking man's PHP (but without PHP's standardization)
>>
>> hehe, I never knew that php had standardisation (I assume u being
>> ironic??) and dont get me started on the probs associated with php
>> (all funcs in the same namespace is a start ...)
>>
>> ... as for xquery it was never intended to be used as a replacement
>> for php ... its an answer to sql
>
> yea, but a lot of people are using it like PHP rather than a replacement for
> SQL on XML. It is the way XML DB vendors recommend you make webapps.
> Writers/editors (at least the ones I have been reading) seem to think this
> is the way to go. It seems like a step backwards.

guilty as charged; I am one of those writers who is advocating using
XQuery in a wider context, but I spend most of my time as a developer
of commercial solutions.

I have been using the mixture of xquery, xslt, xpath + some server
side 'host' language (mainly perl, java) for the past few years with
good effect (and I suspect u have as well ;) minus XQuery).

As any technology, the trick is too know when to stop ... u must
remember how bloated a lot of RDBMS became over time ... same problem
different technology.

I refer back to my original statement of letting your data structure
dictate your technology selection ... really everything flows from
there ... I wouldn't contemplate using XQuery to perform a forensics
low level scan of a hard drive ... nor would I use it to just serve up
static web pages; unless I had some good reason. For example using an
XMLDB as the basis of a CMS makes sense from the editor role, but not
for serving up content to millions of people ... thats why I would put
in place a robust caching infrastructure to remove this issue.

unsurprisingly, what XQuery is really good at is working with XML.

cheers, Jim