XML Support

Rendering SQL Queries as XML (FOR XML Clause)

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Virtuoso extends SQL-92 with the FOR XML clause that allows any SQL result set to be turned into XML according to some simple rules. The notation and functionality are similar to those offered by Microsoft SQL Server and IIS. The FOR XML clause has 3 variants: Make an XML entity from each row of the result set; do not attempt to construct hierarchies. Each row's data is enclosed in a element and each column is either an attribute or child element. A hierarchy is constructed with one level for each table of the join for which at least one column is selected. The table whose column is first mentioned in the selection will be the topmost element, the next table its child, etc. Each level of the tree will consist of one type of element. A parent element will have multiple children if consecutive rows do not differ in the column values coming from the parent element. When a table's column values differ from the previous row, the element and all children thereof are closed and a new element is started, with children filled out from other columns of the result set. This mode gives more control on the resulting tree's structure while requiring a more elaborate query structure. In this mode, the query will be a UNION ALL of many joins and each row will specify exactly one element. Which type of element this is and where in the tree it will be placed are determined by the values of the first two columns, TAG and PARENT. In all modes, columns may either be attributes or sub-elements. The ELEMENT keyword after the FOR XML clause forces all columns to be rendered as sub-elements; attribute are the default.

XML Composing Functions in SQL Statements (SQLX)

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

The preferred means of constructing XML data from SQL is to use the standard SQLX SQL extension. SQLX is a collection of functions added for creating XML entities from standard relational queries. Basically, you write a SQL statement with calls to SQLX functions in the selection and a piece of XML is created. There are five XML composing functions:

Virtuoso XML Services

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Querying Stored XML Data

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Using UpdateGrams to Modify Data

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Updategrams allow database updates to be defined as XML. This is ultimately achieved by mapping the XML nodes against corresponding database columns. Updategrams can be used to replace existing data access components in a middle tier. A typical application will include a middle tier consisting of business logic and data access code. The data access code will interact with the database using disconnected recordsets and command objects calling stored procedures. Most of the data access section of the middle tier can be replaced with updategrams. Most data access tiers (both middle tier code and stored procedures) will deal individually with specific database tables or groups of related tables. This can inhibit performance and often several round trips to the database are required to complete a transaction. Updategrams solve this problem by including all the data in an XML document that is then mapped to database tables and columns. The entire database update can then be accomplished at once. This update can include inserting, updating and deleting data. The xmlsql_update() function supports XML-based insert, update, and delete operations performed on an existing table in the database.

XML Templates

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Virtuoso XML templates allow execution of queries over HTTP in order to achieve any combination of the following: An XML template is an XML file containing a query, optional parameters with default values for the query, a place to specify an XSL stylesheet, and a section for specifying updatagram based synchronization metrics. They are meant to be executed as an XML described short-cut to an query result, an XML document. The XML document returned from calling an XML template can be served raw, or transformed using XSLT. XML templates can be executed from within Virtuoso procedure language using the xml_template() function, or published as SOAP compliant XML Web Services, which makes them accessible to any SOAP and WSDL aware environment.

XML DTD and XML Schemas

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

XQuery 1.0 Support

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

The Virtuoso Server provides support for the XQuery 1.0 XML Query Language specification. This specification is currently in the working draft stage at the W3C XML Query Working Group working in collaboration with the W3C XSL Working Group. Both the syntax and semantics of XQuery will probably vary from version to version. In addition to the XQuery 1.0 standard, which describes the language, the XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0 specification describes a set of built-in functions. As with all W3C in-progress efforts, there is a list of open issues detailing problems and unresolved areas; where these affect Virtuoso's implementation, they are noted below. This chapter is not an XQuery textbook and does not replace XQuery-related specifications of W3C. Only Virtuoso-specific extensions and differences are described here.

XSLT Transformation

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

Virtuoso implements XSLT 1.0 transformations as SQL callable functions. In general, Virtuoso's XSLT processor follows the XSLT 1.0 standard as far as possible without loss of database-related functionality. The most important difference is in error handling. While XSLT rules assume that almost any error must be recovered, Virtuoso will stop the transformation in case of data access error or in case of serious arithmetic error, such as divide by zero. This is due to the greater complexity of the Virtuoso XSLT processor's environment. Standalone processors generally accept a set of files as input parameters, the only output is the resulting transformation as a file, and all configuration parameters are listed on the command line. Virtuoso's XSLT processor may retrieve both data and stylesheets from local filesystems, local tables, remote datasources, or the Web. Parameters of the stylesheet transformation may be prepared by complicated Virtuoso PL procedures and so on. Plain XSLT processors may continue producing "dirty" output; Virtuoso's processor will stop upon encountering serious in order to produce helpful error diagnostics. Another important difference is that Virtuoso has one processor for XSLT, XPath and XQuery. The user will find this convenient because an application may use XSLT-specific functions in XPath expressions, XQuery functions in XSLT, and so on. If extension functions are defined for the XSLT processor, they may also be used in XPath and XQuery expressions without any additional operations. One caveat is that this may invalidate some rules related to the document order of nodes in node-sets. Both the XPath 1.0 and XSLT 1.0 standards say that some functions must process the node that is first in document order from a given node-set. In such cases Virtuoso's processor will process the first node found in the node-set, regardless of whether it is actually the first in document order or not. This is done because the old XPath rule is nonsensical if nodes of the node-set are retrieved from more than one document or are created in the query. The processor follows the old rule for 99% of real expressions. Specifically, it fully matches the standards' rules for all XPath expressions that are free of reverse-order axes and non-standard functions.

XMLType

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

XMLType is a predefined type for representing XML entities as UDT objects. This is compatible with Oracle9i and later. You can get better performance and flexibility by using use plain built-in functions that directly operate with XML entities. All predefined member functions of XMLType for extracting fragments from an XMLType are actually wrappers for xpath_eval() built-in function. You can declare a column of XMLType but the actual type of the created column will be "LONG XML". Thus any XML-related feature that can be used for "LONG XML" column will work with XMLType. E.g. WITH SCHEMA constraint allows you to force stored values to match a particular schema; XML free text index can accelerate search for documents by content etc. XMLType behaves like any user-defined type, with the only difference in type conversion rules. If an XML entity is passed as an argument instead of an instance of XMLType, a new instance of XMLType is created by a constructor that takes the entity as an argument. Similarly, functions that accept XML entities as arguments can also accept an instance of XMLType as an actual value of argument. The following example creates a table with an XMLType column, put two records there and performs a simple search:

Changing XML entities in DOM style

virtuoso.docs@openlinksw.com — Thu, 05 Nov 2009 00:30:50 GMT

An application may need to perform small irregular changes in an XML document. It can be time-consuming to create a modified copy of a whole document for making each small change. It can be also hard to express condition for making the change in terms of XPath in order to use XSLT or XQuery. Virtuoso offers a way to modify an existing XML entity by local operations like "insert a subtree before current node" or "replace one subtree with a given one". These operations are called DOM operations because they are similar to JavaScript operations with the Document Object Model. DOM operations are the only operations that change an existing XML document instead of creating a new modified document. It is very important to understand that one document can be shared between many XML entities so changes made via one entity may affect data accessible via other entities that share the same document. Every XML document has special flags to "lock" its content and thus prevent the content from being changed. E.g. XSLT and XQuery processors optimize access to the source document in hope that every access to any entity will produce the same result during the whole run of the processor. If an extension function will modify the source document in the middle then the result of the processing is probably corrupted and this error may be very hard to detect and debug. To prevent this sort of problems, the XSLT processor locks the source at start and unlock at end so any attempt to modify the source during the run will signal an error. The document can be locked in the following cases: