System Programming Interfaces
The old class
net.sf.saxon.value.DecimalValue has been renamed
and is now a subclass of a new abstract class
net.sf.saxon.value.DecimalValue which also has
net.sf.saxon.value.IntegerValue as a subclass. This gives a closer correspondence between the Java class
hierarchy and the XDM type hierarchy; it reflects the fact that
xs:integer is a subtype of
The specific trigger for the change is to make reflexive extension functions with arguments declared with types such as
OneOrMore<DecimalValue> work correctly when the supplied argument value is an integer.
Continuing the gradual removal of functionality from the global NamePool,
NamePool is no longer responsible
for managing namespace prefixes, and these are now handled by each document model in its own way. Integer namecodes (with
the prefix code in the top 10 bits) are still used in the tiny tree, but nowhere else. As a result, the
method has disappeared from the
NodeInfo interface. To compare names efficiently, use NodeInfo.getFingerprint().
A consequence of the change is that the limit of 1024 prefixes per URI globally has been replaced by a limit of 1024 distinct prefixes declared in each TinyTree document.
Another consequence is that when Saxon needs to allocate an arbitrary prefix to go with a particular URI (for example, when generating
an attribute node during schema validation), it is no longer able to turn to the
NamePool to find prefixes that have previously been used with
that URI. It therefore generates an arbitrary string. However, it is still possible to configure a preferred prefix for a URI manually,
using the call
The marker interface
FingerprintedNode has been removed; the
NodeInfo interface now defines
getFingerprint() which must be provided by all implementations.
implementations that do not use
NamePool fingerprints should return
and should throw an
getFingerprint(). The reason for this change
is that fingerprints were not being used for "wrapper" nodes such as a virtual copy, a snapshot, or a space-stripped copy of
an underlying node even where a the underlying node has a fingerprint.
namespace() method of the Receiver interface now
accepts a NamespaceBindingSet, which
is a generalization of the previous
NamespaceBinding object, allowing multiple namespace bindings to be passed in a single call.
This was done to improve performance of shallow copy: see bug 3011.
On various APIs, Saxon checks that supplied nodes belong to the right
Configuration. This check is now
applied to all nodes, whether or not they use
NamePool fingerprints. (Previously the check was being omitted
for "wrapper" nodes, even though they might use node fingerprints and therefore be tied to a
The MapItem interface, representing an XDM map item, has been changed,
to reflect W3C specification changes
and usage experience. A map is now context-free and error-free. There is now a
conforms() method to test
whether the map conforms to a given type. The type information that is maintained internally (in the
implementation class) has been changed to eliminate the need for a dependency on the Saxon
Configuration. This has enabled
the provision of a context-free XdmMap class at the s9api level.
net.sf.saxon.dom.DocumentBuilderImpl has been dropped, in the belief that the class was
obsolete and unused. There were no references to the class in the code and no unit tests.
The machinery for evaluating queries in "pull event" mode has been dismantled, as it had become
EventIterator classes and their
subclasses have all gone; the method
Expression.iterateEvents() has gone,
XQueryExpression.pull() method is now a deprecated synonym for the
run() method. The
FeatureKeys.LAZY_CONSTRUCTION is no longer recognized. There
is some residual support for
EventIterator objects, but only to the extent needed to support XQJ interfaces.
A Receiver supplied to process
xsl:message output is now
able to determine the error code specified
xsl:message/@error-code attribute. This is made available by sending a
to the message listener, immediately after the
startDocument event. The processing instruction has the target (name) property
set to "error-code", and the data (value) property set to an EQName representation of the error code. The default message listener
ignores this processing instruction, for backwards compatibility. At the s9api level, if a MessageListener is supplied,
the processing instruction is discarded for compatibility reasons, but the new MessageListener2 interface allows
the error code to be reported.