<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="conformance" page="other" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Conformance with other specifications</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Conformance with other specifications"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Conformance with other specifications</h1>
<p>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.</p>
<p>Saxon implements the <code><?xml-stylesheet?></code> processing instruction as described in the
W3C Recommendation <i>Associating StyleSheets with XML Documents</i>.
The <b>href</b> 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.</p>
<p>Saxon's two native tree models, the standard tree and the tiny tree, both support the <code>xml:id</code>
Recommendation. An attribute named <code>xml:id</code> is recognized by the <code>id()</code> function,
provided that its value after space-trimming is a valid <code>NCName</code>. Saxon's schema processor
imposes the constraint that an <code>xml:id</code> attribute, if allowed at all, must be declared as being
of type <code>xs:ID</code>.</p>
<p>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.</p>
<p>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.</p>
<p>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. <i>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.</i></p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="encodings.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
