System Programming Interfaces

The old class net.sf.saxon.value.DecimalValue has been renamed net.sf.saxon.value.BigDecimalValue, 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 xs:decimal. 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, the 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 getNameCode() 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 configuration.getNamePool().suggestPrefix(prefix, uri).

The marker interface FingerprintedNode has been removed; the NodeInfo interface now defines methods hasFingerprint() and getFingerprint() which must be provided by all implementations. NodeInfo implementations that do not use NamePool fingerprints should return false for hasFingerprint(), and should throw an UnsupportedOperationException for 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.

The 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 NamePool.)

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 HashTrieMap 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.

The class 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 redundant. The PullEventSource, PullEvent, and EventIterator classes and their subclasses have all gone; the method Expression.iterateEvents() has gone, and the XQueryExpression.pull() method is now a deprecated synonym for the run() method. The configuration property 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 in the xsl:message/@error-code attribute. This is made available by sending a processingInstruction event 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.