[xquery-talk] XQuery Platform Support

john.zink at prudential.com john.zink at prudential.com
Fri Oct 17 10:46:13 PDT 2003

If I had to have this app out the door next week I would be using XSLT, but
luckily it doesn't need to be completed until about 3rd QTR next year.
In my opinion XQuery appears to be a bit more powerful with it's built in
functions, ability to create user defined functions and it's SQL like FLWR
expressions.  I've never been a big fan of the XSLT syntax.

              "Michael Kay" <mhk at mhk.me.uk>                                                                                            
                                                          To:                                         <john.zink at prudential.com>,      
                                                           <talk at xquery.com>                                                           
              Thursday October 16, 2003 03:28 PM          cc:                                                                          
                                                          Subject:   RE: [xquery-talk] XQuery Platform Support                         

Surely, if this is a real application, you should be writing it in XSLT?

Never mind the merits of the languages, surely a technology that has
been stable for nearly four years is more appropriate to your needs than
one that is still in beta?

Michael Kay

> -----Original Message-----
> From: talk-bounces at xquery.com
> [mailto:talk-bounces at xquery.com] On Behalf Of john.zink at prudential.com
> Sent: 16 October 2003 15:29
> To: talk at xquery.com
> Subject: RE: [xquery-talk] XQuery Platform Support
> OK..Let me see if I can explain it a bit clearer.
> We basically have 2 scenarios where a rules engine needs to
> be implemented. For our "new business" process I need an
> engine that examines application type questions and returns a
> result for the policy.  The result can be either accept or
> reject the policy.  The decision is made based upon a
> collection of rules.  For example if you have 3 speeding
> tickets in the last month you will be declined.  This engine
> has been created as I explained before.  The new engine is
> replacing COM components that have all the rules hard coded
> in the form of "IF-THEN-ELSE" statements.  The user can now
> create the rules based on a schema that describes the message
> the client will pass to the engine.  The engine takes the
> rules entered by the user and converts them to XQuery
> expressions.  The engine than runs the XQuery expressions
> against the XML being passed from the client to
> determine the result for the policy (hold or accept).    The second
> scenario is we have another engine running on the mainframe
> that processes policies when they renew on a yearly basis.
> This engine is basically a COBOL program that processes a
> sequential input file and updates a VSAM file with the
> results.  This engine processes thousands of records every
> night in a batch process.   I would like to use the same
> client application
> for building the rules as I mentioned in the first scenario.
> I would then need a way to get a mainframe program that runs
> in a batch process to somehow process the XQuery statements.
> I believe it would be too slow to send mainframe records down
> to the server to run against the distributed
> engine.   I only have a short window for the mainframe batch
> process.  Hope
> this clarifies my situation.  I've just started to examine
> the mainframe process so I haven't really formulated any real
> solutions for the mainframe side of the problem.
> John Z
>               "James Governor"
>               <jgovernor at redmonk.com>                     To:
> <john.zink at prudential.com>,
> <talk at xquery.com>
>                                                           cc:
>               Thursday October 16, 2003 09:48 AM
> Subject:   RE: [xquery-talk] XQuery Platform Support
> I am not sure from your question exactly what scenario you're
> talking to.
> However it is worth noting that IBM this week acquired a
> mainframe data integration firm called CrossAccess, which was
> pitched as filling out its DB2 Information Integrator (II) strategy

DB2 II is where IBM plans to instantiate xQuery, and as such it looks as
if IBM is potentially moving in a helpful direction. Assuming xquery is
mapped to mainframe data sources accessed natively using CrossAccess
connector technology.

Until IBM delivers a native XML store for DB2 however, some of the
xQuery productization is on hold.

IBM was partnering with Nimble Technologies for xQuery support, but
Actuate acquired Nimble, so I am not sure of the status of that deal.

Hope that helps a little but I am not sure we understood your problem.

As SoftwareAG points out, Tamino already offers xQuery support on the

Are you running 390 or ZOS, or VM/VSE or whatever? Which IBM mainframe

-----Original Message-----
From: talk-bounces at xquery.com [mailto:talk-bounces at xquery.com] On Behalf
Of john.zink at prudential.com
Sent: Thursday, October 16, 2003 2:07 PM
To: talk at xquery.com
Cc: ktegels at msn.com
Subject: RE: [xquery-talk] XQuery Platform Support

Not in the Yukon beta, but I am in the Whidbey alpha program. The
mainframe OS is IBM.

talk at xquery.com

More information about the talk mailing list