Financial integration tool vendor C24 has added a unique XQuery optimization to their Integration Objects product that allows full XML XQuery and XSLT capabilities on non-XML documents without the overhead of first converting those non-xml documents into instances of XML.
XQuery is a language written for querying complex XML documents which, it allows you to query data from diverse datasources with the return data automatically aggregated as XML. The W3C XQuery specification and 8 related specifications (including XSLT 2.0 and XPath 2.0) were submitted to the W3C on June 8th. All are currently in Candidate Recommendation stage, and it is expected that they will become W3C Proposed Recommendations since the industry has already begun embracing XQuery in their products. BEA uses XQuery in it's AquaLogic suite, as does DataDirect, both treat XQuery as an integration tool - allowing the query across multiple heteogenous sources with XML as output. Even JSR 170/Java Content Repositories use it as their standard query mechanism.
When used for integration, documents are commonly transformed first in to XML and then transformed using XQuery or XSLT before being transformed back into the destination format. This multi-stage processing makes many EAI/ESB/SOA solutions extremely slow and inefficient for transforming non-XML data model formats.
C24 asked Mike Kay (author of the XSLT programmers reference, editor of W3C's XSLT 2.0 specification and founder of Saxonica) to assist in extending C24's Integration Objects's API to include a native XPath 2.0, XSLT 2.0 and XQuery engine that fits into the C24 Integration Objects (C24 IO) modelling and binding tool kit. This feature enables full XML XQuery and XSLT capabilities on non-XML documents without the overhead of using XML instance documents as the common format, instead, C24's Integration Objects (a Java object representation of the underlying document) is the intermediary, allowing quicker in-memory query performance. The process is described in more detail in Mike Kay's whitepaper on XQuery (written for C24):
XQuery is a language written for querying complex XML documents which, it allows you to query data from diverse datasources with the return data automatically aggregated as XML. The W3C XQuery specification and 8 related specifications (including XSLT 2.0 and XPath 2.0) were submitted to the W3C on June 8th. All are currently in Candidate Recommendation stage, and it is expected that they will become W3C Proposed Recommendations since the industry has already begun embracing XQuery in their products. BEA uses XQuery in it's AquaLogic suite, as does DataDirect, both treat XQuery as an integration tool - allowing the query across multiple heteogenous sources with XML as output. Even JSR 170/Java Content Repositories use it as their standard query mechanism.
When used for integration, documents are commonly transformed first in to XML and then transformed using XQuery or XSLT before being transformed back into the destination format. This multi-stage processing makes many EAI/ESB/SOA solutions extremely slow and inefficient for transforming non-XML data model formats.
C24 asked Mike Kay (author of the XSLT programmers reference, editor of W3C's XSLT 2.0 specification and founder of Saxonica) to assist in extending C24's Integration Objects's API to include a native XPath 2.0, XSLT 2.0 and XQuery engine that fits into the C24 Integration Objects (C24 IO) modelling and binding tool kit. This feature enables full XML XQuery and XSLT capabilities on non-XML documents without the overhead of using XML instance documents as the common format, instead, C24's Integration Objects (a Java object representation of the underlying document) is the intermediary, allowing quicker in-memory query performance. The process is described in more detail in Mike Kay's whitepaper on XQuery (written for C24):
we can apply the XQuery and XSLT directly to the IO object without having to convert it to XML. A SWIFT message can, for example, be transformed without having to pass by an intermediate XML format. This saves time (latency) and complexity in integration. An XQuery could be written to process a comma-delimited file or an XSL transform could be used to display details from a SWIFT message.
