Home · All Classes · Modules

QtXmlPatterns Module

The QtXmlPatterns module implements PyQt's XQuery support. More...

Types

• class QAbstractMessageHandler
• class QAbstractUriResolver
• class QAbstractXmlNodeModel
• class QAbstractXmlReceiver
• class QSimpleXmlNodeModel
• class QSourceLocation
• class QXmlFormatter
• class QXmlItem
• class QXmlName
• class QXmlNamePool
• class QXmlNodeModelIndex
• class QXmlQuery
• class QXmlResultItems
• class QXmlSchema
• class QXmlSchemaValidator
• class QXmlSerializer

from PyQt4 import QtXmlPatterns

• Introduction
• Why use XQuery?
• Using QtXmlPatterns
• Command line utility
• XQuery HOWTO
• Qt's and XQuery's Data Model
• Integrating with Custom Data
• More on Custom Data
• Security Considerations
• Query Injection
• Denial of Service Attacks
• Features and Conformance
• Conformance
• Resource Loading

XQuery is a pragmatic language that allows XML to be queried and created in fast, concise and safe ways.

 <bibliography>
 {
     doc("library.xml")/bib/book[publisher = "Addison-Wesley" and @year > 1991]/
     <book year="{@year}">{title}</book>
 }
 </bibliography>

XQuery is tailor made for selecting and aggregating information in safe and efficient ways. Hence, if an application selects and navigates data, XQuery could be a possible candidate for implementing that in a quick and bug-free manner. With QAbstractXmlNodeModel, these advantages are not constrained to XML files, but can be applied to other data as well.

Maybe XQuery can be summarized as follows:

• Pragmatic functionality: XQuery has a slew of expressions for sorting, selecting and filtering data in typically one liners. Aggregation functions like avg(), abs() and max() helps further doing this concisely.
• Development speed: pick one of the queries in this document and imagine writing the equivalent code in C++ or Java. Compared to a one or two liner of XQuery, that would be quite a task to develop, test and maintain.
• Type safety: in XQuery values have strong types, and the type system respect that. For instance, one cannot pass the return value from current-time() to a function that expects xs:integer, and the value of an attribute or element can be atomic values such as xs:date or xs:double, as opposed to only strings.
• Interoperability: XML has a gazillion of rules for how things should be and not be. Adhering to these are important since it ensures data is consistently interpreted and that different XML processors can handle the same data. However, knowing, and keeping in mind, all these rules is a daunting task. The QtXmlPatterns engine does all this checking behind the scenes. The user just writes queries, and as long as an error isn't flagged, one can sleep tight, knowing ones data will be correctly processed with product XYZ, or appearing in the same manner on the other side of the planet.

On top of that the language is designed to be high level such that it is easy to analyze what the user is computing. With this, it is easier to optimize both speed and memory use of XML operations.

      #include <QtXmlPatterns>

      QT += xmlpatterns

See QXmlQuery for how to use the C++ API.

See A Short Path to XQuery for a round of XQuery.

XQuery and Qt has different data models. All data in XQuery takes the form of sequences of items, where an item is either a node, or an atomic value. Atomic values are the primitives found in W3C XML Schema, and nodes are usual XML nodes, although they might represent other things using QXmlNodeModelIndex and QAbstractXmlNodeModel.

Atomic values, when not being serialized, are represented with QVariant. The mappings are as follows.

XQuery is a language designed for, and modeled on XML. However, it doesn't have to be constrained to that. By sub-classing QAbstractXmlNodeModel one can write queries on top of any data that can be modeled as XML.

By default when QtXmlPatterns is asked to open files or to produce content, this is done using an internal representation. For instance, in this query:

 <result>
     <para>The following Acne removers have shipped, ordered by shipping date(oldest first):</para>
     {
         for $i in doc("myOrders.xml")/orders/order[@product = "Acme's Acne Remover"]
         order by xs:date($i/@shippingDate) descending
         return $i
     }
 </result>

an efficient internal representation is used for the file myOrders.xml. However, by sub-classing QAbstractXmlNodeModel one can write a query on any data, by mapping XML elements and attributes to the custom data model. For instance, one could write a QAbstractXmlNodeModel sub-class that mirrors the file system hierarchy like this:

 <?xml version="1.0" encoding="UTF-8"?>
 <directory name="home">

     <file name="myNote.txt" mimetype="text/plain" size="8" extension="txt" uri="file:///home/frans/myNote.txt">
         <content asBase64Binary="TXkgTm90ZSE=" asStringFromUTF-8="My Note!"/>
     </file>

     <directory name="src">
         ...
     </directory>

     ...

 </directory>

and hence have a convenient way to navigate the file system:

 <html>
     <body>
         {
             $myRoot//file[@mimetype = 'text/xml' or @mimetype = 'application/xml']
             /
             (if(doc-available(@uri))
              then ()
              else <p>Failed to parse file {@uri}.</p>)
         }
     </body>
 </html>

Converting a data model to XML(text) and then read it in with an XML tool has been one approach to this, but that has disadvantages such as being inefficient. The XML representation is separated from the actual data model, and that two representations needs to be maintained simultaneously in memory.

With QAbstractXmlNodeModel this conversion is not necessary, nor are two representation kept at the same time, since QXmlNodeModelIndex is a small, efficient, stack allocated value. Also, since the XQuery engine asks the QAbstractXmlNodeModel for the actual data, the model can create elements, attributes and data on demand, depending on what the query actually requests. For instance, in the file system model above, the model doesn't have to read in the whole file system or encoded the content of a file until it is actually asked for.

In other words, with QAbstractXmlNodeModel it's possible to have one data model, and then use the power of the XQuery language on top.

Some examples of possible data models could be:

• The internal document representation in a word processor
• Dependencies within a build system
• the hierarchy(or graph) that links with HTML documents forms(for a web crawler)
• Images and meta data in an image collection
• The D-Bus interfaces available on the system
• The file system hierarchy(as seen above)
• The QObject hierarchy.

The documentation for QAbstractXmlNodeModel has the details for implementing this.

In the case of CSV files, which are text, a QAbstractXmlNodeModel sub-class is used again in order to expose the comma-separated file as XML, such that a query can operate on it.

See Avoid the dangers of XPath injection, Robi Sen or Blind XPath Injection, Amit Klein for deeper discussions.

• The regular expressions support is currently not conformant but follows that of Qt's QRegExp standard syntax.
• Operators between xs:time, xs:date, and xs:dateTime are incomplete
• Formatting of very large or very small xs:double, xs:float, and xs:decimal values may be wrong.
• Some corner cases involving namespaces and element constructors are wrong.

XML 1.0 and XML Namespaces 1.0 are supported, as opposed to the 1.1 versions. When strings are fed into the query using QStrings, the characters must be XML 1.0 characters. Otherwise, the behavior is undefined. This is not checked.

Since XPath 2.0 is a subset of XQuery 1.0, that is supported too.

The specifications discusses conformance further: XQuery 1.0: An XML Query Language. W3C's XQuery testing effort can be of interest as well, XML Query Test Suite.

Currently fn:collection() does not access any data set, and there is no API for providing data through the collection. As a result, evaluating fn:collection() returns the empty sequence. We hope to provide functionality for this in a future release of Qt.

When opening XML files, this is done with support for xml:id. In practice this means elements that has an attribute by name xml:id, can be looked up fairly quickly with the fn:id() function. See xml:id Version 1.0 for details.

Note: Only queries encoded in UTF-8 are supported.

URIs are first passed to QAbstractUriResolver(see QXmlQuery.setUriResolver()) for possible rewrites.