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

# .NET platform

On the .NET platform, extension functions represented as methods in a .NET assembly may now be invoked dynamically. These may be written in any .NET language. The facility also allows methods in the standard .NET system classes to be invoked. For further details, see Writing extension functions (.NET)

In accordance with .NET naming conventions, the interface `QueryResolver` has been renamed `IQueryResolver`.

Some convenience methods have been added to the Saxon.Api classes. These include:

- XdmNode.Parent returns the parent of a node

- XdmNode.GetAttributeValue returns the string value of a named attribute of an element

- XdmNode.EnumerateAxis has an optional second argument to select nodes with a given name

- QName has a new constructor to return a QName value by resolving a lexical QName against the in-scope namespaces for a given element

- Processor has properties giving the Saxon product version

A method has been added to the `Processor` class allowing collections to be registered. This simply maps a collection URI to an `IEnumerable` interface; the `IEnumerable` is responsible for delivering a sequence of URIs, which will then be resolved as if by a call to the doc() function.

The .NET platform is rather more fussy than Java about requiring streams to be closed after use: failure to close a stream, even when only reading a file, can cause subsequent attempts to access the same file to fail. This has led to some problems with the API design, in terms of defining whose responsibility it is to close a stream. The normal rule is that the component that creates a stream is responsible for closing it. However, there are some cases where this does not work: for example if a stream is created by an XmlResolver, the XmlResolver is not called again when reading finishes. To cope with these difficulties Saxon now allows an `AugmentedSource` object to wrap a `Stream` or `Reader` with a request to close the stream as soon as end of file is detected. This facility is available in the Java product as well as .NET, but it is specifically used by the .NET Saxon.Api to ensure that files are closed when no longer required.

A method is now provided in the XSLT API allowing the transformation to be controlled using an `<?xml-stylesheet?>` processing instruction in the source document. There are some restrictions: the media type of the processing instruction is ignored, and the URI (href pseudo-attribute) must either be in the form `#xxxx` to identify an embedded stylesheet in the same document, or it must be a URI with no fragment identifier. Because the Microsoft XML parser does not report `ID` attributes to the application, Saxon searches for an `xsl:stylesheet` or `xsl:transform` element with the right value for its `id` attribute, without requiring that the attribute is typed as an ID in the DTD.

The handling of errors in the API is now better documented. A new exception class `DynamicError` has been introduced.

Next