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.
SaxonJ 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.
SaxonJ 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 JDOM2 trees: in these cases, the virtual XPath view that is created maps one XPath text node to a sequence of adjacent DOM or JDOM2 nodes.