| SAXONICA | 
Localized formatting of dates and numbers in French has been added. Thanks to Luc Rochefort and colleagues for this contribution.
Saxon now checks that all the documents involved in a query or transformation were built under the same
            Configuration. Previously this was not always checked; the consequence of breaking this rule was
            that documents in different configurations could used the same document numbers and thus 
            be considered to have the same identity, causing incorrect results for operations that are sensitive to
            node identity, for example elimination of duplicates in a path expression. Note that some of the issued
            API sample applications have required changing as a result of these stricter checks.
         
The PreparedSchema object now has methods allowing the application to iterate over all the components
            in a schema: previously it was only possible to retrieve components by name.
         
On the Transform command line, it is now possible to nominate an OutputURIResolver using
            the new -or option.
         
Casting of a QName to a QName (typically a type derived from QName) and from a NOTATION to a NOTATION is now supported. This is a late change in the specification: see W3C bugzilla entry 2678.
In many cases the error that occurs when an attribute node is added to an element after adding child nodes (such as elements or text nodes) to the parent element is now detected statically. This also applies to the error that occurs when an attribute node is added directly to a document node. The change affects both XSLT and XQuery.
When reading input using a StAX parser, (a) ignorable whitespace is now recognized (if reported by the parser)
            and stripped according to the configuration settings in use, and (b) unparsed entities are recognized and reported,
            so they are available to the XSLT functions unparsed-entity-uri() and unparsed-entity-public-id().
         
When a Saxon tree is accessed using DOM interfaces (using the NodeOverNodeInfo wrapper), namespace nodes
            in the Saxon tree are now presented as attributes in the DOM interface.
         
If an unknown encoding is requested, the transformation now fails with error SESU0007 as defined in the serialization specification. Previously Saxon used ASCII as a fallback. Similarly, error SESU0013 is raised if the HTML output method is used with the version parameter set to a value other than "4.0" or "4.01".
The DocumentBuilderImpl class, which is Saxon's implementation of the JAXP DocumentBuilder
            interface, now has additional non-JAXP methods allowing a Configuration to be supplied. It is 
            necessary to register a Configuration if the new document is to be used within a query or
            transformation, to ensure that it has a unique identity and uses the same NamePool. Saxon
            now checks that a document (whatever the object model) that is supplied as input to a query or transformation
            uses the same Configuration as that query or transformation.
         
The ContentHandlerProxy class no longer implements Locator directly; instead it provides this service
            through a separate class ContentHandlerProxyLocator. This change is made because ContentHandlerProxy previously implemented both Receiver
            and Locator, both of which had a getSystemId() method, and there was a tension between the semantics of the
            two methods.
         
It is now possible to specify at compile time that tracing is to be compiled in to the executable code, without
            specifying a TraceListener until run-time. This is a more sensible approach when the compiled code
            is executed repeatedly.
         
The serialization pipeline now processes cdata-section-elements before processing character
            maps, as required by the latest revision of the specification. This means that characters in an element where
            CDATA sections are used are not subject to character mapping.
         
It is now possible to customize the serialization pipeline. A SerializerFactory can be registered with the
            Configuration, subclassing the standard SerializerFactory, and by overriding methods in the standard 
            SerializerFactory it is possible to replace any of the components of the serialization pipeline with
            customized subclasses; it is also possible to replace the entire pipeline, should you wish to.