SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
» | Version 9.1 (2008-07-02)
| Version 9.0 (2007-11-03)
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

# Diagnostics and Tracing

If requested using the `-l` (letter ell) option on the command line (or the equivalent in the API), Saxon now maintains column numbers as well as line numbers for source documents. The information is available to applications using a new extension function `saxon:column-number()`, or at the level of the Java API via a new method on the `NodeInfo` interface, `getColumnNumber()`. (Third-party implementations of `NodeInfo` will need to implement this method; by default it can return -1). Note that the information is only as good as that supplied by the XML parser: SAX parsers report for an element the line and column of the ">" character that forms the last character of the element's start tag.

Errors that occur during schema validation of an input document now display both line number and column, as do static errors detected in a stylesheet or schema. Dynamic errors occurring during expression evaluation still contain a line number only.

After a dynamic error, Saxon now outputs a stack trace - that is, a representation of the XSLT or XQuery call stack. This feature is now available in Saxon-B, it was previously only in Saxon-SA. The stack trace has been improved at the same time (it now shows changes to the context item made by `xsl:apply-templates` or `xsl:for-each`).

The information in the stack trace is also available programmatically through the method `iterateStackFrames()` on the `XPathContext` object.

The formatted print of the stack trace can be retrieved as a string from within a query or stylesheet using the new extension function `saxon:print-stack()`.

There are some internal changes as a result of this development, which may be noticeable to applications that do debugging or tracing. The `InstructionInfoProvider` interface has disappeared; instead all expressions (including instructions) now implement `InstructionInfo` directly, as do container objects such as `UserFunction` and `Template`. Generally the `getProperties()` method of `InstructionInfo` is not so well supported; applications requiring properties of expressions should cast the `InstructionInfo` to the required class and get the information directly from the expression tree.

The `InstructionInfo` object no longer contains a `NamespaceResolver` - it is no longer needed because all names are now represented as expanded names.

New methods are available to allow the output from the `trace()` function to be directed to a specified output stream, or to be discarded.

A new option `FeatureKeys.TRACE_LISTENER_CLASS` allows the TraceListener to be nominated as a class name, rather than as an instance of the class. This is useful in environments such as Ant where the values of configuration properties must be supplied as strings. A new instance of the class is created for each query or transformation executed under the Configuration. The existing option `FeatureKeys.TRACE_LISTENER` remains available.

Next