1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
|
<html>
<head>
<title>Standards Conformance</title>
<body leftmargin="150" bgcolor="#ddeeff"><font face="Arial, Helvetica, sans-serif">
<div align=right><a href="index.html">SAXON home page</a></div>
<p><b><font FACE="Arial, Helvetica, sans-serif" color="#FF0080" size="7">
Standards Conformance</font></b></p>
<h2>XSLT and XPath conformance</h2>
<p><i>SAXON XSLT implements the
XSLT 1.0 and XPath 1.0 Recommendations from the World Wide Web Consortium, found at
<a href="http://www.w3.org/TR/1999/REC-xslt-19991116">
http://www.w3.org/TR/1999/REC-xslt-19991116</a> and
<a href="http://www.w3.org/TR/1999/REC-xpath-19991116">
http://www.w3.org/TR/1999/REC-xpath-19991116</a>, which are
referred to here collectively as "XSLT"</i></p>
<p>SAXON is 100% conformant to the mandatory requirements of these standards. It also
implements certain facilities defined in the draft XSLT 1.1 specification, even where
the XSLT 1.0 specification says that these should be rejected as errors.</p>
<p>SAXON will automatically convert a result tree fragment to a node-set when required,
as defined in the draft XSLT 1.1 specification.
</p>
<p>SAXON supports the <xsl:document> element defined in the draft XSLT 1.1 specification.
The implementation is not yet complete: in particular (a) the href attribute is interpreted
as a filename relative to the current directory (not the base URI), and (b) the provisions
relating to use of <xsl:document> while the current output destination is a temporary tree
are not yet implemented.</p>
<p>SAXON supports the use of <b>xsl:script</b> to define external Java functions. The archive
attribute is available only with a JDK1.2 or later JVM. The rules for identifying a Java
class and a method within the class are as defined in the working draft XSLT 1.1 specification.
The Context object implements the XSLT-defined XSLTContext interface.</p>
<p>SAXON supports the use of <b>xml:base</b> to define the Base URI of a node, as defined in
the XSLT 1.1 specifications, except in the case of the base URI of a processing instruction contained
in an external entity.</p>
<p>SAXON is dependant on the user-selected XML parser to ensure conformance with the XML 1.0
Recommendation and hte XML Namespaces Recommendation.</p>
<p>SAXON implements the <?xml-stylesheet?> 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>
<hr>
<h3>Limitations</h3>
<ul>
<li><p>SAXON supports language-dependent sorting and numbering only for English, but offers
APIs that allow support of other languages via user-written additions.</p></li>
</ul>
<h3>Documentation</h3>
<p>The XSLT specification says that the documentation for an implementation should specify
which URI schemes
are supported. SAXON supports the URI scheme implemented by the Java java.net.URL class, with
the optional addition of a fragment identifier, as described below.
Additionally,
SAXON allows the user to nominate a URIResolver class which can be used to implement any URI scheme
the user wants.</p>
<p>The XSLT specification says that the documentation for an implementation should specify for which
media types fragment identifiers are supported. The standard URI resolver supports access to
XML documents
only. A simple fragment identifier is allowed, consisting of the value of an ID attribute in the
document. The effect is to return the subdocument rooted at the element with this identifier if there
is one, or an empty document otherwise. For example, the URI mydoc.xml#aaa locates the XML document
mydoc.xml, and if it contains an element <eeee id="aaa">, where id is an attribute of type ID, then
the document retrieved is an XML document with this <eeee> element as its outermost (document)
element.</p>
<p>The values of the vendor-specific system properties are:</p>
<table>
<tr><td width="120">xsl:version</td><td>1.0</td></tr>
<tr><td>xsl:vendor</td><td>SAXON n.n.n from Michael Kay</td></tr>
<tr><td>xsl:vendor-url</td><td>http://users.iclway.co.uk/mhkay/saxon/index.html</td></tr>
</table>
<p>All three values are subject to change in future releases. Users wishing to test whether the
processor is SAXON are advised to test whether the xsl:vendor system property starts with the string
"SAXON".</p>
<h3>Extensions</h3>
<p>SAXON implements a number of extensions to standard XSLT, following the rules for extension
functions and extension elements where appropriate. The extensions are documented in
<a href="extensions.html">extensions.html</a>. They are all implemented in accordance with
the provisions in the standard for extensibility.</p>
<h2>Character encodings supported</h2>
<p>The following is the list of encodings recognized by the built-in AElfred
parser (case-insensitive):</p>
<pre>
ISO-8859-1, 8859_1, ISO8859_1
US-ASCII, ASCII
UTF-8, UTF8
ISO-10646-UCS-2, UTF-16, UTF-16BE, UTF-16LE
</pre>
<p>The encodings available on output are the intersection of:</p>
<pre>
ascii, us-ascii, utf-8, utf8, iso-8859-1, iso-8859-2
ko18-r, cp1250, windows-1250, cp1251, windows-1251
(again case-insensitive)
</pre>
<p>with whatever your Java VM supports.</p>
<p>If you select an encoding that the Java VM recognizes, but which is not in the
above list, then the output will be written in the requested encoding, but all non-ASCII
characters will be written as character references.</p>
<h2>XML 1.0 Conformance</h2>
<p>Saxon can be used with any SAX-conformant XML parser. The extent of XML conformance
depends entirely on the chosen parser.</p>
<p>The default parser is a version of Ælfred. This parser has the following
known limitations:</p>
<ul>
<li>Where a reference to an external entity occurs in a different resource from the
relevant entity declaration, the base URI used for resolving the system identifier
of the external entity is that of the resource containing the entity reference, not
that containing the entity declaration.</li>
<li>There are some limitations in the handling of parameter entities, which only
arise in unusually complex DTDs.</li>
</ul>
<h2>DOM Conformance</h2>
<p>SAXON accepts input (both source document and stylesheet) from any standards-compliant DOM
implementation.</p>
<p>SAXON allows the result tree to be attached to any Document or Element node of an existing
DOM. Any DOM implementation can be used, provided it is mutable.</p>
<p>SAXON's internal tree structure (which is visible through the Java API, including the case
where Java extensions functions are called from XPath expressions) conforms with the minimal
requirements of the DOM level 2 core Java language binding. This DOM interface is read-only,
so all attempts to call updating methods throw an appropriate DOM exception. No optional
features are implemented. The DOM interfaces to Saxon's tree structure do not reveal namespace
nodes as attributes. This means it is not possible to get information about namespace
declarations except by calls such as getPrefix() and getNamespaceURI() on Element and Attr nodes).</p>
<p>If an extension function returns a DOM Node or NodeList, this must consist only of Nodes
in a tree constructed using Saxon. Since Saxon's trees cannot be updated using DOM methods, this
means that the nodes returned must either be nodes from the original source tree, or nodes from
a tree constructed using Saxon's proprietary API. It is <b>not</b> possible to construct
the tree using DOM methods such as createElement() and createAttribute().</p>
<h2>JAXP 1.1 Conformance</h2>
<p>Saxon implements the JAXP 1.1 API (including TrAX), as defined in
<a href="http://java.sun.com/aboutJava/communityprocess/review/jsr063/index.html">JSR-63</a>.
Saxon implements the interfaces in the javax.xml.transform package in full, including support for
SAX, DOM, and Stream input, and SAX, DOM, and Stream output.</p>
<p>There are restrictions in using transform() on a DOMSource when the node to be transformed
is a node other than the root (i.e. the DOM Document node). These apply only if the
supplied DOM is a third-party DOM, not if it is a Saxon-constructed tree.
Specifically, if the start node
is not the root then it must be an element; and it must not have an ancestor or preceding-sibling
node, or an ancestor with a preceding-sibling node, that is an entity reference node or CDATA
section node.</p>
<p>Saxon also implements the javax.xml.parsers API. The SAX interfaces are implemented in full.
The DOM interfaces are limited by the capabilities of the Saxon DOM, specifically the fact that
it is read-only. Nevertheless, the DocumentBuilder may be used to construct a Saxon tree, or to
obtain an empty Document node which can be supplied in a DOMResult to hold the result of a
transformation.</p>
<a name="errorrecovery"><h2>Error recovery policy</h2></a>
<p>Where the XSLT specification requires that an error be signaled, Saxon produces an error
message and terminates stylesheet execution. In the case of errors detected at compile
time, it attempts to report as many errors as possible before terminating; in the case
of run-time errors, it terminates after the first error.</p>
<p>Where the XSLT specification states that the processor may recover from an error, Saxon takes
one of three actions as described in the table below. Either it signals the error and terminates
execution, or it recovers silently from the error in the manner permitted by the specification,
or it places the action under user control. In the latter case there are three options: report the
error and terminate, recover silently, or (the default) recover after writing a warning
to the system error output stream. These actions can be modified by supplying a user-defined
ErrorListener.</p>
<p>Handling of individual recoverable errors is described in the table below.</p>
<table>
<tr><td><b>Error</b></td><td><b>Action</b></td></tr>
<tr>
<td valign="top">There is more than one template rule that matches a node, with the
same import precedence and priority</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">There is more that one xsl:namespace-alias statement for a given prefix,
with the same import precedence</td>
<td valign="top">Recover silently</td>
</tr>
<tr>
<td valign="top">An element name defined using xsl:element is invalid</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">An attribute name defined using xsl:attribute is invalid</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">There are several attribute sets with the same import precedence that
define the same named attribute</td>
<td valign="top">Recover silently</td>
</tr>
<tr>
<td valign="top">A processing-instruction name defined using xsl:processing-instruction is invalid</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">A node other than a text node is written to the result tree while instantiating
xsl:attribute, xsl:comment, or xsl:processing-instruction</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">Invalid characters are written to the content of a comment or processing instruction</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">An attribute node or namespace node is written directly to the root of a result
tree fragment, or to any other node that is not an element node.</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">The document() function identifies a resource that cannot be retrieved</td>
<td valign="top">User option</td>
</tr>
<tr>
<td valign="top">There are several xsl:output elements specifying the same attribute with the same
import precedence</td>
<td valign="top">Recover silently</td>
</tr>
<tr>
<td valign="top">disable-output-escaping is used for a text node while instantiating
xsl:attribute, xsl:comment, or xsl:processing-instruction</td>
<td valign="top">Recover silently</td>
</tr>
<tr>
<td valign="top">disable-output-escaping is used for a text node within a result tree fragment
that is subsequently converted to a string or number</td>
<td valign="top">Recover silently</td>
</tr>
<tr>
<td valign="top">disable-output-escaping is used for a text node containing a character that cannot
be output using the target encoding</td>
<td valign="top">Recover silently</td>
</tr>
</table>
<hr>
<p align="center"><a HREF="mailto:mhkay@iclway.co.uk">Michael H. Kay</a> <br>
6 September 2001 </p>
</body>
</html>
|
