TransQuery comprises a small, flexible set of XSLT conventions and processing model constraints that enable the use of XSLT as a query language over multiple XML documents. In a nutshell, TransQuery provides a simple contract between XSLT authors and XSLT processing models--an agreement that a certain name ("tq:input") refers to a node-set of zero or more root nodes. For more information, see the TransQuery Specification.
The purpose of TransQuery is to promote interoperability between XML document management systems (and XML databases) that use XSLT as their primary data access language.
Traditional XSLT processors are designed to process individual XML documents on the fly. They generally require the entire source tree to be loaded into memory. This obviously has some negative performance and scalability implications for large documents. TransQuery addresses interoperability between implementations of a new kind of XSLT processor--one that instead functions as a query engine over an XML database, thus reversing the common paradigm of known stylesheet and unknown input.
No. XQuery, as currently drafted, differs from XSLT in some important respects. For one thing, XQuery will be a strongly-typed language, which is important for applications that require certain kinds of guarantees about the types of query results. XSLT 1.0 was not designed to support these kinds of guarantees.
Moreover, XQuery does not yet exist in a standard form. XSLT, on the other hand, is a standard and widely used XML manipulation language. TransQuery is thus able to satisfy the demand for an immediately useable interoperability specification for XML database implementations, rather than forcing vendors to wait for the release of a new query language specification, whose future, as with any new specification, is uncertain.
Finally, this question ultimately may be a moot one, depending on how closely a future version of XSLT aligns itself with XQuery. Current collaboration between the W3C XSL and XML Query Working Groups is evident, for example, in the XPath 2.0 Requirements and the XQuery 1.0 and XPath 2.0 Data Model documents.
XPath is not a standard query language, in and of itself. The Recommendation makes this clear:
XPath is intended primarily as a component that can be used by other specifications. Therefore, XPath relies on specifications that use XPath (such as XPointer and XSLT) to specify criteria for conformance of implementations of XPath and does not define any conformance criteria for independent implementations of XPath.In particular, XPath does not specify how its abstract expression values should be serialized. Any implementation of XPath alone has to make vendor-specific decisions about how to serialize attributes without elements, boolean values, etc. XSLT, on the other hand, defines a larger chunk of the processing model, such that both the input and output are XML documents.
Moreover, XSLT is a full-featured transformation language. XPath does not allow you to execute close-to-engine transformations, aggregation, sorting, etc. XSLT, when given integrated access to the underlying operators of an XML database, opens up a world of possibility for XML database applications. These are the promises of XQuery. XSLT can answer them today.
Finally, TransQuery describes conventions that go the last mile to full interoperability between XML database implementations, in a fully standard way.
If the W3C XML Query Use Cases document is any indication, then yes. See the TransQuery demo, for XSLT solutions to the XML Query use cases.
TransQuery does not directly address the implementability and optimizability of XSLT over large data sets. Vendors will address these issues, and the market will ultimately decide.
As is the case with the current draft of XQuery, the current TransQuery specification does not address update. However, a future draft or version of TransQuery may address the possibility of using XSLT as an update language for XML documents.
There is a TransQuery SourceForge project that hosts a prototype implementation of the TransQuery interface. In its current form, it makes use of an existing XSLT processor, SAXON.
Chris Bayes is working on an ongoing experimental JavaScript implementation of some of the various ideas that were explored on the TransQuery discussion list.