SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| Version 8.7 (2006-02-24)
| Version 8.6.1 (24 November 2005)
| Version 8.6 (3 November 2005)
| Version 8.5.1 (26 August 2005)
| Version 8.5 (2 August 2005)
| Version 8.4 (4 April 2005)
» | Version 8.3 (11 February 2005)
| Version 8.2 (21 December 2004)
| Version 8.1.1 (8 October 2004)
| Version 8.1 (24 September 2004)
| Version 8.0 (1 June 2004)
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
The XPath API
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# Pull Processing

Saxon 8.3 contains some new classes to support a pull pipeline. At present this should be regarded as preliminary and experimental; it provides some new ways of providing input to Saxon and reading results from Saxon, but plays no significant role within the product architecture yet. Interfaces are likely to change.

A new interface, `PullProvider` is included. This interface is modelled on the `XMLStreamReader` interface that forms part of `StAX`, but modified to use Saxon concepts such as NamePools and SequenceIterators. This interface allows a caller to read an XML document by a sequence of calls on the method `next()`: each such call advances the position of a cursor and makes information available about the current context. Typically, `next()` reports that it has read the start of an element, a text node, a comment, the end of an element node, and so on. Attributes and namespaces are not reported as events, but information about them is available to the caller immediately after the `START_ELEMENT` event is notified.

The `PullProvider` can in fact read any XPath sequence, containing nodes and atomic values. When a node is encountered, the client can "drill down" to get the events within the subtree rooted at that node. (Alternatively, the client can skip the node and move on). It is not possible to navigate in arbitrary directions from the node, because the node may have no real existence in memory: this is a streaming interface.

A class `PullSource` is available that wraps a `PullProvider` as a JAXP Source object. This allows any `PullProvider` to be supplied as input to a transformation or query.

It is possible to obtain a `PullProvider` that reads the contents of an Saxon tree, starting at a given node. There are two variants of this: `TreeWalker` which can handle any tree (that is, any implementation of the `NodeInfo` interface), and `TinyTreeWalker`, which is optimized for the TinyTree.

It is possible to bridge between Saxon's pull and push interfaces using a `PullPushCopier`. This reads events from a `PullProvider` and sends equivalent events to a `Receiver`.

A `PullProvider` is available that interfaces to a StAX pull-parser. This class is called `StaxBridge`. It has been tested with pull parsers from BEA and Sun. Both these parsers are currently early releases and have been found to be rather buggy: no doubt they will improve in subsequent versions.

The `StaxBridge` class is the only class in Saxon that depends on the presence of the StAX API. For this reason, it is not bundled as part of the general `saxon8.jar` file. Instead, it is included for the time being in the `samples` directory. There is no dependency on any particular StAX parser: it will pick up whatever parser is on the classpath, or selected using the relevant Java system properties.

A class `PullFilter` is available that simply joins two `PullProviders` end-to-end. This can be subclassed (in the same way as the `XMLFilter` class in SAX) to provide a wide variety of components that analyze or modify the event stream. This allows pull pipelines to be built in very much the same way as Saxon's existing push pipelines.

An eventual aim of this work is to enable tree-construction expressions to be evaluated in pull mode. This will allow lazy evaluation of trees in the same way as Saxon currently makes heavy use of lazy evaluation of sequences. For example, given a construct such as `<e a="{$x}"/>` (in either XSLT or XQuery), Saxon would be able to return to the caller a sequence of events (in this case, just a start-element and end-element event) without ever building a tree in memory. This is similar to what happens today using the push pipeline when writing a final result tree, especially in XSLT. For XQuery, however, where it is more common to construct many small intermediate trees, being able to switch between pull and push processing for such expressions offers considerable advantages.

Next