SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| Version 8.9 (2007-02-12)
| Version 8.8 (2006-09-05)
| Version 8.7.3 (2006-06-13)
| Version 8.7.2 (2006-04-19)
| Version 8.7.1 (2006-04-13)
| 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
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# XQuery changes

The option declaration `declare saxon:option "method=html"` has been changed so it can now be used to override the defaults `method=xml` and `indent=yes` as well as supplying additional serialization parameters. Previously the above two properties could not be changed except from the command line (or from a Java application).

The namespace for local-functions has changed to `http://www.w3.org/2005/04/xquery-local-functions`. (In Saxon 8.4 and 8.5, the month/year part was `2005/02`.)

It is now possible to register a ModuleURIResolver which is used to handle the URIs specified in the import module declaration. The ModuleURIResolver is given the requested module URI and the set of supplied location URIs, and returns a set of JAXP StreamSource objects each containing an InputSource or Reader containing the text of a query module, together with its base URI. The resolver can return a Reader if it wishes to decide the encoding itself, or an InputSource if it wishes to leave encoding decisions up to Saxon. A user-written ModuleURIResolver can also delegate to the system-supplied ModuleURIResolver if required.

A query module can now import other modules in the same namespace, and such imports can contain cycles (A can import B, which imports A). Cycles involving more than one namespace are not allowed. (Note: this small feature has resulted in a surprising amount of internal code change, because it means that it is no longer possible to fix up every variable reference as soon as it is encountered, and it is no longer possible to fix up all the function calls in a module as soon as the module has been parsed. As a result of the changes, it would now be perfectly feasible to allow recursive import across namespaces, and to allow forwards references to global variables, but these restrictions are retained in the interests of conformance to the specification.)

Another consequence of this change is that it removes the restriction that a module import must be preceded by a schema import of the types appearing in functions and variables declared by that module. The schema import and module import can now appear in any order.

A circularity among global variable definitions is now reported as a static error.

Next