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 the DOM implementation included in the Oracle JDK, and other DOM implementations are known to vary. Saxon has been used successfully with the Oracle XDK 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.