Tool development: by Perl-wrapped XQuery

[David A. Lee]

> While XProc is probably the cleanest solution, another approach in
> particular for ad-hoc scripting might be to use an existing scripting
> language that can run on top of the JVM (1), e.g. jython or jruby.
> This gives you the flexibility of handy scripting but doesn't incur
> the overhead of re-parsing huge documents. And of course on the JVM
> you'll find implementations for everything-XML, from XSLT via XQuery
> and XML databases to various validation tools etc., all nicely
> co-existing based on the DOM and SAX (2).
>
> Regards
> Martin
>   

jypthon or jruby solve the performance problem but they dont solve the 
complexity problem.
The fact is these XML API technologies are a royal pain to call and 
worse to glue to together.
If you can find one vendor/ implementation that has all the pices its a 
tad easier (document types match !) but its still a bit of hell.
Then add technologies that VendorA doesnt do and try to wrap VendorB's 
data type and push it through VendorA's API.
I think you'll find it about as painful to to use jruby or jython to say 
call  xinclude , then rng validate then xquery then pass its results to 
xslt as writing it in pure java.
In xproc this is very clean, but admittedly verbose.  (guess about 40 
lines of xproc code).
In xmlsh its as simple as 
    xinclude file | rngvalidate schema | xquery -f schema | xslt -f 
stylesheet

To get these kind of languages (jruby etc) into shape where XML is 
actually *easy to use* is going to require work.  
Possibly at the language level to make it really easy.
If this is done to more scripting languages (making it both efficient 
and simple to use) rather then just "possible" I suspect adoption of the 
core technologies would skyrocket.  

Thats what we need, IMHO, is more *simplicity* of using and intemixing 
the core xml tools in a way that doesn't incur huge performance costs.
But if they dont include the core technologies such as XQuery , XSLT 
(2.0 ideally) , xinclude , validation ... in such a way that they can be 
easily intermixed accessed then people wont use them.  The reason people 
are using scripting languages is for ease of use.
I talked to a Ruby programmer at work after a demonstration on XQuery 
and his answer was "I can do that in ruby ... why would I want to learn 
xquery ?  And ruby can do a LOT more then just xml processing " ... 
After seeing some of his code I had to admit he had a point.  I still 
have been unable to successfully convince him the value of xquery over 
Ruby's XML API's.  Although he's never had to do anything *complicated* 
... but because of that he cant envision the need for a different 
language.   He's at the stage I was when I first started XML Programming 
in java ... I would look at XSLT programs "Why would I want to write 
something that complicated when I can just use the easy DOM calls in 
java.   It wasn't until several years of having to do *difficult* 
transformations that I finally realized how big my java programs were 
getting.



David A. Lee
http://x-query.com/mailman/listinfo/talk  
http://www.calldei.com
http://www.xmlsh.org
812-482-5224