SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
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
| Introduction
| XSLT 2.0 conformance
| XPath 2.0 conformance
| XQuery 1.0 Conformance
| XML Schema 1.0
| XML Schema 1.1
| Serialization
| XQuery Update 1.0
» | Conformance with other specifications
| Character Encodings Supported
| JAXP Conformance
| XQJ Conformance

# Conformance with other specifications

Saxon is dependent on the user-selected XML parser to ensure conformance with the XML 1.0 or 1.1 Recommendation and the XML Namespaces Recommendation. The syntax for names appearing in XPath expressions follows the XML 1.0 or 1.1 rules depending on Saxon configuration settings.

Saxon implements the `<?xml-stylesheet?>` processing instruction as described in the W3C Recommendation Associating StyleSheets with XML Documents. The href pseudo-attribute must be a URI identifying an XML document containing a stylesheet, or a URI with a fragment identifier identifying an embedded stylesheet. The fragment must be the value of an ID attribute declared as such in the DTD.

Saxon's two native tree models, the standard tree and the tiny tree, both support the `xml:id` Recommendation. An attribute named `xml:id` is recognized by the `id()` function, provided that its value after space-trimming is a valid `NCName`. Saxon's schema processor imposes the constraint that an `xml:id` attribute, if allowed at all, must be declared as being of type `xs:ID`.

Saxon on the Java platform works with any SAX2-conformant XML parser that is configured to enable namespace processing. There is one limitation: on the startElement() call from the XMLReader to the ContentHandler, the QName (that is, the third argument) must be present. According to the SAX2 specification, namespace-aware parsers are not obliged to supply this argument. However, all commonly-used parsers appear to do so.

Saxon on the Java platform should work with any DOM-conformant XML parser, however, Saxon's DOM interface is tested only with Crimson and Xerces, and DOM implementations are known to vary widely. Saxon has been used successfully with the Oracle DOM implementation, though this is not included in the standard test suite and problems have occasionally been reported with this combination.

When a XOM tree is supplied as the transformation input, Saxon does not combine adjacent text nodes into a single node. Adjacent text nodes can occur as the result of user modifications to the tree, or as a result of the presence of CDATA sections or entity references, depending on the options in force when the tree was constructed. This restriction no longer applies to DOM and JDOM trees: in these cases, the virtual XPath view that is created maps one XPath text node to a sequence of adjacent DOM or JDOM nodes.

Next