<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="conformance" page="update" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XQuery Update 1.0</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title" content="Saxonica: XSLT and XQuery Processing: XQuery Update 1.0"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XQuery Update 1.0</h1>
<p>Saxon 9.4 implements XQuery Update Facility 1.0, which finally reached Recommendation status on 17 March 2011.
All features, including
optional features, are implemented.</p>
<p>Update is currently supported only on documents built using the <code>linked</code> tree model.</p>
<p>There are several limitations worth noting:</p>
<ul>
<li content="para">
<p>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.</p>
</li>
<li content="para">
<p>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 <code>equals()</code> or <code>isSameNodeInfo()</code>
will reveal that they refer to the same nodes. After an update, it is in general not safe to continue using
existing <code>NodeInfo</code> 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.</p>
</li>
<li content="para">
<p>The <code>put()</code> function is implemented using the same run-time support code as <code>xsl:result-document</code>,
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 <code>put()</code> must not write to the same URI. However, it does use the XQuery semantics for resolving
the relative URI.</p>
</li>
<li content="para">
<p>The specification change introduced by <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9432" class="bodylink">bug 9432</a>,
which is included in the final Recommendation, has not been implemented in Saxon 9.4. The effect of this is that an updated
document may sometimes be missing the namespace undeclaration <code>xmlns=""</code> where the specification requires it.</p>
</li>
</ul>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="other.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
