Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Feasibility of "do all application coding in the XML langu
 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 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
