SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Notices
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
| Introduction
| XSLT 2.0 conformance
| XPath 2.0 conformance
| XQuery 1.0 Conformance
| XML Schema 1.0
| XML Schema 1.1
| Serialization
» | XQuery Update 1.0
| Conformance with other specifications
| Character Encodings Supported
| JAXP Conformance
| XQJ Conformance

# XQuery Update 1.0

Saxon 9.1 implements the Candidate Recommendation for XQuery Update 1.0. All features, including optional features, are implemented.

Update is currently supported only on documents built using the `linked` tree model.

There are several limitations worth noting:

- The specification requires that updates should be atomic: that is, if any failure occurs, the original document is restored to its original state. Saxon meets this requirement unless revalidation is requested. If failures occur during the revalidation phase, these cannot currently be rolled back. Of course, this only affects the in-memory copy of the document; the application should be organized so that in this situation it is possible to revert to the copy on disk.

- The specification requires that node identity should be preserved across updates. The extent to which this requirement is met by Saxon is debatable. Saxon allows several Java objects to represent the same node. With the linked tree this applies in particular to attribute nodes: two requests to get all the attributes of a node will return different Java objects, though comparisons using `equals()` or `isSameNodeInfo()` will reveal that they refer to the same nodes. After an update, it is in general not safe to continue using existing `NodeInfo` objects, and the effect of doing so is undefined. This means that it is impossible to determine in any reliable way whether the old nodes have the same identity as the new nodes. In practice, with the linked tree implementation, it is safe to continue using variables that refer to element nodes (where there is always one Java object per node), but it is not safe in the case of attribute nodes.

- The `put()` function is implemented using the same run-time support code as `xsl:result-document`, and it currently imposes similar restrictions: for example, it must not be called from within a variable initialization or function body, and it must to write to a URI that has been read during the execution of the query; also, two calls on `put()` must not write to the same URI. However, it does use the XQuery semantics for resolving the relative URI.

Next