Project

Profile

Help

How to connect?
Download (151 KB) Statistics
| Branch: | Revision:

he / src / userdoc / conformance.xml @ 8ddaa514

1
<?xml version="1.0" encoding="utf-8"?>
2
<article id="conformance" title="Standards Conformance">
3
   <h1>Standards Conformance</h1>
4

    
5

    
6
   <p>This section of the documentation describes the extent to which Saxon conforms to external
7
      specifications, notably W3C language specifications and Java API specifications.</p>
8

    
9
   <p>Statements of conformance are made here in good faith, and are based on the results of running
10
      W3C test suites. To the extent that these test suites are incomplete, however, there may be
11
      edge case non-conformances that are not captured here. Any information about discrepancies or
12
      non-conformances not noted here will be welcomed, and the differences will either be corrected
13
      in the product, or documented in a future revision of this section.</p>
14
   
15
   <p>A non-conformance with a W3C specification is generally treated as a bug, and may be fixed in a
16
   maintenance release even where this changes the behaviour of existing applications. However, where
17
   non-conformances are found that cannot be fixed without serious risk of disruption, the fix may be deferred
18
   to the next major release of Saxon.</p>
19
   
20
   <section id="xslt20" title="XSLT 2.0 conformance">
21
      <h1>XSLT 2.0 conformance</h1>
22
      
23
      <p>Since Saxon 9.8, Saxon no longer offers an XSLT 2.0 processor: the product now implements
24
      XSLT 3.0 only, and is not tested for XSLT 2.0 conformance.</p>
25
      
26
      <p>XSLT 3.0 has a very high level of backwards compatibility with XSLT 2.0, so all
27
      existing stylesheets should continue to run. The only significant difference when you process
28
      a 2.0 stylesheet with a 3.0 processor is that you will no longer get errors if you use constructs
29
      that are permitted in 3.0 but not in 2.0.</p>
30
      
31
      <p>There are a few very minor incompatibilities between XSLT 3.0 and XSLT 2.0 listed in the W3C specifications: for example,
32
      some error codes have changed.</p>
33

    
34

    
35
   </section>
36
   <section id="xslt30" title="XSLT 3.0 conformance">
37
      <h1>XSLT 3.0 conformance</h1>
38

    
39
      <p>The release of Saxon 9.8 was timed to coincide with the final publication of the <a
40
            href="http://www.w3.org/TR/xslt-30/" class="bodylink">XSLT 3.0 
41
            Recommendation</a>, published in June 2017 (at http://www.w3.org/TR/xslt-30/). The
42
         implementation of Saxon 9.8 was closely aligned with this specification with very few
43
         restrictions. Some of these restrictions, noted below, are lifted in 9.9.</p>
44
      
45
      
46
      <h2 class="subtitle">Test results</h2>
47
      
48
      <p>At the time of release Saxon-EE 9.9 passes all 11435 applicable tests in the W3C XSLT 3.0 test suite. For the first time,
49
         this includes testing that it always returns the right error code in the case of error tests. Tests are run
50
         with bytecode enabled or disabled, with stylesheets that are exported and re-imported, and with JIT compilation
51
         enabled and disabled (but with JIT enabled, static errors in stylesheets are not always detected if the code
52
         is never executed). Appropriate subsets of the tests are also run with Saxon-PE and Saxon-HE. Tests are run on both
53
         the Java and .NET platforms.
54
      </p>
55
      
56
      <p>The only tests that are not included in these results are:</p>
57
      
58
      <ul>
59
         <li>3 tests (document-2004/5/6) that use non-ASCII characters in test filenames, which causes problems
60
         for the Mercurial client used by our test driver.</li>
61
         <li>1178 tests labeled with dependencies that Saxon does not satisfy. These have not been analyzed in detail. Many of them are specifically intended
62
            only to be run with an XSLT 2.0 processor. Some of them depend on specific Unicode versions or specific localization languages.</li>
63
         <li>Tests in the <code>regex-classes</code> test set, which have not been updated to the latest Unicode standards: minor changes to the list
64
            of characters included in a particular category will cause a test failure. (Despite this, Saxon passes 98
65
         out of 120 of these tests.)</li>
66
         <li>The "posture and sweep" tests, which test that the streamability of particular expressions is correctly calculated. Saxon does not run these
67
         tests because (a) they are not in line with the final XSLT 3.0 recommendation, and (b) there is no conformance requirement on a product to
68
         use the algorithms appearing in the spec, provided that the final result is correct.</li>
69
      </ul>
70
      
71
      <p>Although the W3C XSLT Working Group has ceased operation, the W3C test suite continues to be developed by
72
      volunteers, and Saxonica remains an active contributor. Conformance issues raised by Saxon users typically
73
      result in new test cases being added to the test suite.</p>
74
      
75
      
76
      <h2 class="subtitle">Conformance overview</h2>
77

    
78

    
79
      <p>Broadly speaking:</p>
80

    
81
      <ul>
82
         <li>
83
            <p>Saxon-HE implements the following features of the XSLT 3.0 specification:</p>
84
            
85
            <ul>
86
               <li>Basic Conformance</li>
87
               <li>Serialization</li>
88
               <li>XPath 3.1</li>
89
               <li>Compatibility* (that is, XSLT 1.0 compatibility mode)</li>
90
              <li>Dynamic Evaluation§ (the <code>xsl:evaluate</code> instruction)</li>
91
              <li>Higher-Order Functions§</li>
92
            </ul>
93
            
94
            <p>* From 9.8.0.7, XSLT 1.0 backwards-compatibility mode was reinstated in Saxon-HE. In
95
               earlier versions of 9.8, this mode required
96
               Saxon-PE or higher (that is, Saxon-HE will reject stylesheets that specify <code>version="1.0"</code>).</p>  
97
            
98
            <p>§ Support for dynamic evaluation and higher-order functions moved into Saxon-HE
99
            with the 10.0 release; previously these features required Saxon-PE or higher.</p>
100
            
101
           <p>Saxon-HE includes support for the language features associated with XSLT 3.0 packages, but with limited operational
102
               support. Specifically, Saxon-HE allows compiled stylesheet packages to be loaded from filestore, but creating such packages
103
               requires Saxon-EE.</p>
104
         </li>
105
         <li>
106
                     
107
            <p>Saxon-PE provides a range of Saxon-specific extensions, and allows users to implement their
108
            own extensions, for example by calling out to user-defined functions.</p>
109
           <p>Where possible, extensions  are implemented
110
             in a Saxon-specific namespace as required by the W3C standard. Some experimental
111
           syntax extensions, which have been proposed for future standardization, are
112
           available if explicitly enabled using a configuration switch.</p>
113
         </li>
114
         <li>
115
            <p>Saxon-EE adds support for two further optional features of the XSLT 3.0 specification, specifically:</p>
116
            
117
            <ul>
118
               <li>Schema-Awareness</li>
119
               <li>Streaming</li>
120
            </ul>
121
               
122
            <p>Saxon-EE also provides many
123
               more operational options not specifically tied to language features, for example bytecode generation,
124
               the ability to export packages in compiled form, and multi-threaded execution.</p>
125
         </li>
126
      </ul>
127

    
128
      <p>For information on streaming, see <a class="bodylink" href="/sourcedocs/streaming"
129
            >Streaming of Large Documents</a>.</p>
130

    
131
      <p>For information on using packages, see <a class="bodylink" href="/using-xsl/compiling">Compiling a Stylesheet</a>.</p>
132

    
133
      <p>Saxon (from release 9.8) acts as an XSLT 3.0 processor whether this is explicitly requested or not.
134
         Specifying <code>version="1.0"</code> or <code>version="2.0"</code> does not prevent the use of 3.0 features;
135
         rather it switches on "backwards compatibility mode" as defined in the XSLT 3.0 specification.</p> 
136
         
137
 
138
      <p>The XSLT 3.0 specification requires support for XPath 3.0 plus selected features from XPath 3.1: let's call the resulting combination
139
      XPath 3.0+. Support for XPath 3.1 is optional, but even if it is available, XSLT 3.0 processors are required to provide a mode of operation
140
      that is restricted to XPath 3.0+. Saxon provides such a mode of operation, but there may be edge cases where it is not 100% conformant, behaving as specified
141
      in XPath 3.1 rather than as specified in XPath 3.0.</p>
142

    
143
      <p>There are no known restrictions.</p>
144

    
145
 
146
      <p>New XSLT 3.0 features implemented in Saxon include the following. The links are to sections
147
         of the documentation that summarize the usage of each element, and in some cases describe details of the Saxon implementation.</p>
148

    
149
      <ul>
150
         <li>
151
            <p>The <a class="bodylink code" href="/xsl-elements/iterate">xsl:iterate</a>
152
               instruction</p>
153
         </li>
154
         <li>
155
            <p>The <a class="bodylink code" href="/xsl-elements/mode">xsl:mode</a> declaration</p>
156
         </li>
157
         <li>
158
            <p>The <a class="bodylink code" href="/xsl-elements/merge">xsl:merge</a> instruction</p>
159
         </li>
160
         <li>
161
            <p>The <a class="bodylink code" href="/xsl-elements/try">xsl:try</a> and <a
162
                  class="bodylink code" href="/xsl-elements/catch">xsl:catch</a> instructions</p>
163
         </li>
164
         <li>
165
            <p>The <a class="bodylink code" href="/xsl-elements/evaluate">xsl:evaluate</a>
166
               instruction</p>
167
         </li>
168
         <li>
169
            <p>The <a class="bodylink code"
170
               href="/xsl-elements/source-document">xsl:source-document</a> instruction (Saxon-EE
171
               only)</p>
172
         </li>
173
         <li>
174
            <p>The <a class="bodylink code" href="/xsl-elements/fork">xsl:fork</a> instruction
175
               (Saxon-EE only)</p>
176
         </li>
177
         <li>
178
            <p>The <a class="bodylink code" href="/xsl-elements/accumulator">xsl:accumulator</a>
179
               instruction</p>
180
         </li>
181
         <li>
182
            <p>The <a class="bodylink code" href="/xsl-elements/assert">xsl:assert</a>
183
               instruction</p>
184
         </li>
185
         <li>
186
            <p>The <a class="bodylink code" href="/xsl-elements/map">xsl:map</a> and <a
187
                  class="bodylink code" href="/xsl-elements/map-entry">xsl:map-entry</a>
188
               instructions</p>
189
         </li>
190
         <li>
191
            <p>The <a class="bodylink code" href="/xsl-elements/on-empty">xsl:on-empty</a>, <a
192
                  class="bodylink code" href="/xsl-elements/on-non-empty">xsl:on-non-empty</a>, and
193
                  <a class="bodylink code" href="/xsl-elements/where-populated"
194
                  >xsl:where-populated</a> instructions</p>
195
         </li>
196
         <li>
197
            <p>The <a class="bodylink code" href="/xsl-elements/package">xsl:package</a> element, <a
198
                  class="bodylink code" href="/xsl-elements/use-package">xsl:use-package</a>
199
               declaration, and <a class="bodylink code" href="/xsl-elements/override"
200
                  >xsl:override</a> element</p>
201
         </li>
202
         <li>
203
            <p>The <a class="bodylink code" href="/xsl-elements/accept">xsl:accept</a> and <a
204
                  class="bodylink code" href="/xsl-elements/expose">xsl:expose</a> elements</p>
205
         </li>
206
         <li>
207
            <p>The <code>visibility</code> attribute of the <a class="bodylink code"
208
                  href="/xsl-elements/function">xsl:function</a>, <a class="bodylink code"
209
                  href="/xsl-elements/template">xsl:template</a>, <a class="bodylink code"
210
                  href="/xsl-elements/attribute-set">xsl:attribute-set</a>, <a class="bodylink code"
211
                  href="/xsl-elements/variable">xsl:variable</a> and <a class="bodylink code"
212
                  href="/xsl-elements/mode">xsl:mode</a> declarations</p>
213
         </li>
214
         <li>
215
            <p>The <code>select</code> attribute of the <a class="bodylink code"
216
                  href="/xsl-elements/copy">xsl:copy</a> instruction</p>
217
         </li>
218
         <li>
219
            <p>The <code>composite</code> attribute of the <a class="bodylink code"
220
               href="/xsl-elements/for-each-group">xsl:for-each-group</a> instruction and <a
221
                  class="bodylink code" href="/xsl-elements/key">xsl:key</a> declaration</p>
222
         </li>
223
         <li>
224
            <p>The <code>static</code> attribute of the <a class="bodylink code"
225
                  href="/xsl-elements/variable">xsl:variable</a> and <a class="bodylink code"
226
                  href="/xsl-elements/param">xsl:param</a> declarations</p>
227
         </li>
228
         <li>
229
            <p>The <code>[xsl:]default-mode</code> standard attribute</p>
230
         </li>
231
         <li>
232
            <p>The <a class="bodylink code" href="/functions/fn/copy-of">copy-of()</a> and <a
233
                  class="bodylink code" href="/functions/fn/copy-of">snapshot()</a> functions</p>
234
         </li>
235

    
236
         <li>
237
            <p>The syntax of patterns has been generalized.</p>
238
         </li>
239

    
240
      </ul>
241
      
242
      <p>Packages are fully implemented. Packages can be exported in compiled form only in Saxon-EE, but importing
243
         of compiled packages works with Saxon-PE provided that the package does not require features
244
         beyond the capabilities of the particular Saxon edition. The preferred mechanism for locating packages
245
         in Saxon 9.8 is to register them in the configuration file.</p>
246

    
247
      
248

    
249
      <h2 class="subtitle">Checklist of Implementation-Defined Items</h2>
250

    
251
      <p>The following list describes the way in which Saxon implements the features that the
252
         specification leaves implementation-defined. The numbering of items in the list corresponds
253
         to the numbering in the checklist provided as <a
254
            href="http://www.w3.org/TR/xslt-30/#implementation-defined-features" class="bodylink"
255
            >Appendix F of the XSLT 3.0 specification</a>.</p>
256

    
257
      <p>
258
         <i>The implementation-defined features are grouped into categories for convenience.</i>
259
      </p>
260
      
261
      <div class="div2">
262
         <h3>
263
            <i>F.1 Application Programming Interfaces</i>
264
         </h3>
265
         <p>
266
            <i>This category covers interfaces for initiating a transformation, setting its
267
               parameters, initializing the static and dynamic context, and collecting the results.
268
               In general terms, it is implementation defined how input is passed to the processor
269
               and how it returns its output. This includes the interpretation of URIs used to refer
270
               to stylesheet packages and modules, source documents and collections, collations, and
271
               result documents.</i>
272
         </p>
273
         <p>&#x25BA; For information on Saxon's APIs for XSLT transformation, see 
274
            <a class="bodylink" href="/using-xsl/embedding">Invoking XSLT from an application</a>.</p>
275
         <p>
276
            <i>More specifically:</i>
277
         </p>
278
         <ol>
279
            <li>
280
               <p>
281
                  <i>A processor MAY also provide a mode of operation in which static errors in parts of the 
282
                     stylesheet that are not evaluated can go unreported. (See 2.14 Error Handling)</i>
283
               </p>
284
               <p>&#x25BA; By default, in Saxon-EE, the body of a template rule is compiled only the first
285
                  time that the template rule is evaluated; static errors in unused template rules are
286
               therefore not detected. This setting can be changed for example by using <code>-opt:-j</code>
287
               on the command line.</p>
288
            </li>
289
            <li>
290
               <p>
291
                  <i>If the initialization of any global variables or parameter depends on the
292
                     context item, a dynamic error can occur if the context item is absent. It is
293
                     implementation-defined whether this error occurs during priming of the
294
                     stylesheet or subsequently when the variable is referenced; and it is
295
                     implementation-defined whether the error occurs at all if the variable or
296
                     parameter is never referenced. (See 2.3.2 Priming a Stylesheet)</i>
297
               </p>
298
               <p>&#x25BA; The error typically only occurs when the variable is actually referenced.</p>
299
            </li>
300
            <li>
301
               <p>
302
                  <i>The way in which an XSLT processor is invoked, and the way in which values are
303
                     supplied for the source document, starting node, stylesheet parameters, and
304
                     base output URI, are implementation-defined. (See 2.3.2 Priming a
305
                     Stylesheet)</i>
306
               </p>
307
               <p>&#x25BA; For information on Saxon's APIs for XSLT transformation, see 
308
                  <a class="bodylink" href="/using-xsl/embedding">Invoking XSLT from an application</a>.
309
                  Transformations can also be invoked from the command line (see 
310
                  <a class="bodylink" href="/using-xsl/commandline">Running XSLT from the command line</a>).</p>
311
            </li>
312
            <li>
313
               <p>
314
                  <i>The way in which a base output URI is established is implementation-defined.
315
                     (See 2.3.6 Post-processing the Raw Result)</i>
316
               </p>
317
               <p>&#x25BA; For the <code>s9api</code> interface: <code>XsltTransformer30.setBaseOutputURI()</code>.
318
                  For the command line: the <code>-o</code> option.</p>
319
            </li>
320
            <li>
321
               <p>
322
                  <i>It is implementation-defined how a package is located given its name and
323
                     version, and which version of a package is chosen if several are available.
324
                     (See 3.5.2 Dependencies between Packages)</i>
325
               </p>
326
               <p>&#x25BA; Packages can be explicitly loaded into a configuration, for example by
327
                  use of the <code>-pack</code> option on the command line or by the method 
328
               <code>XsltCompiler.importPackage()</code>.</p>
329
               <p>&#x25BA; It is also possible to list the available packages in a configuration file,
330
               with their versions, and to indicate which of several versions is preferred if the using
331
               package indicates no preference.</p>
332
            </li>
333
            <li>
334
               <p>
335
                  <i>In the absence of an <code>[xsl:]default-collation</code> attribute, the
336
                     default collation <span class="verb">may</span> be set by the calling
337
                     application in an implementation-defined way. (See 3.7.1 The default-collation
338
                     Attribute)</i>
339
               </p>
340
               <p>&#x25BA; The name of the default collation may be specified as a configuration option
341
                  on the XSLT compiler: <code>XsltCompiler.declareDefaultCollation()</code>.</p>
342
            </li>
343
            <li>
344
               <p>
345
                  <i>It is implementation-defined what forms of URI reference are acceptable in the
346
                        <code>href</code> attribute of the <code>xsl:include</code> and
347
                        <code>xsl:import</code> elements, for example, the URI schemes that may be
348
                     used, the forms of fragment identifier that may be used, and the media types
349
                     that are supported. The way in which the URI reference is used to locate a
350
                     representation of a stylesheet module, and the way in which the stylesheet
351
                     module is constructed from that representation, are also
352
                     implementation-defined. (See 3.11.1 Locating Stylesheet Modules)</i>
353
               </p>
354
               <p>&#x25BA; A user-written <code>URIResolver</code> may be supplied to handle any
355
                  kind of URI that the application wishes to handle.</p>
356
            </li>
357
            <li>
358
               <p>
359
                  <i>The statically known documents, statically known collections, and the
360
                     statically known default collection type are implementation-defined. (See 5.3.1
361
                     Initializing the Static Context)</i>
362
               </p>
363
               <p>&#x25BA; These values are all empty; no documents, collections, or collection types
364
                  are known statically.</p>
365
            </li>
366
            <li>
367
               <p>
368
                  <i>Implementations may provide user options that relax the requirement for the
369
                        <code>doc</code> and <code>collection</code> functions (and therefore, by
370
                     implication, the <code>document</code> function) to return stable results. The
371
                     manner in which such user options are provided, if at all, is
372
                     implementation-defined. (See 5.3.3 Initializing the Dynamic Context)</i>
373
               </p>
374
               <p>&#x25BA; Document stability may be relaxed by calling the extension function
375
                  <code>saxon:discard-document()</code>. Collection stability can be controlled
376
               at the configuration level, or at the level of an individual collection by means 
377
               of a query parameter in the collection URI.</p>
378
            </li>
379
            <li>
380
               <p>
381
                  <i>The implicit timezone for a transformation is implementation-defined. (See
382
                     5.3.3.2 Other Components of the XPath Dynamic Context)</i>
383
               </p>
384
               <p>&#x25BA; The value is taken from the system clock, as exposed by the Java platform.
385
               Alternatively, the current date and time may be set programmatically, and the implicit
386
               timezone is taken from this value.</p>
387
            </li>
388
            <li>
389
               <p>
390
                  <i>The default collection is implementation-defined. (See 5.3.3.2 Other Components
391
                     of the XPath Dynamic Context)</i>
392
               </p>
393
               <p>&#x25BA; A default collection name may be defined at <code>Configuration</code> level;
394
                  this is then resolved in the same way as any other collection URI. In the absence of such
395
               a definition, the default collection is empty.</p>
396
            </li>
397
            <li>
398
               <p>
399
                  <i>Streamed processing may be initiated by invoking the transformation with an
400
                     initial mode declared as streamable, while supplying the initial match
401
                     selection (in an implementation-defined way) as a streamed document. (See 6.6.4
402
                     Streamable Templates)</i>
403
               </p>
404
               <p>&#x25BA; If the initial mode is streamable, then for streaming to take place, the
405
                  source document must be supplied as a <code>StreamSource</code> or <code>SAXSource</code>.
406
               It is also possible to use the output of one transformation as the streamed input to another.</p>
407
            </li>
408
            <li>
409
               <p>
410
                  <i>The mechanism by which the caller supplies a value for a stylesheet parameter
411
                     is implementation-defined. (See 9.5 Global Variables and Parameters)</i>
412
               </p>
413
               <p>&#x25BA; In s9api, use <code>Xslt30Transformer.setStylesheetParameters()</code>.
414
                  In JAXP, use <code>Transformer.setParameter()</code>. On the command line, use
415
                  a <code>name=value</code> pair as a command line option.</p>
416
            </li>
417
            <li>
418
               <p>
419
                  <i>The detail of any external mechanism allowing a processor to enable or disable
420
                     checking of assertions is implementation-defined. (See 23.2 Assertions)</i>
421
               </p>
422
               <p>&#x25BA; On the command line, use the <code>-ea</code> option to enable assertion checking.
423
                  In s9api, assertions must be enabled at compile time using <code>XsltCompiler.setAssertionsEnabled(true)</code>;
424
                  if required they can then be disabled at evaluation time using <code>Xslt30Transformer.setAssertionsEnabled(false)</code>.</p>
425
            </li>
426
            <li>
427
               <p>
428
                  <i>The way in which the results of the transformation are delivered to an
429
                     application is implementation-defined. (See 25 Transformation Results)</i>
430
               </p>
431
               <p>&#x25BA; Results are delivered to a user-supplied result document handler.
432
                  The default mechanism serializes result trees to files in filestore.</p>
433
            </li>
434
            <li>
435
               <p>
436
                  <i>It is implementation-defined how the URI appearing in the <code>href</code>
437
                     attribute of <code>xsl:result-document</code> affects the way in which the
438
                     result tree is delivered to the application. There <span class="verb"
439
                        >may</span> be restrictions on the form of this URI. (See 25.1 Creating
440
                     Secondary Results)</i>
441
               </p>
442
               <p>&#x25BA; This can be customized by use of a user-supplied result document handler.
443
                  By default, result documents are serialized to files in filestore, which implies that the URIs must
444
               use the <code>file</code> URI scheme.</p>
445
            </li>
446
            <li>
447
               <p>
448
                  <i>If serialization is supported, then the location to which a final result tree
449
                     is serialized is implementation-defined, subject to the constraint that
450
                     relative URI <span>references</span> used to reference one tree from another
451
                     remain valid. (See 26 Serialization)</i>
452
               </p>
453
               <p>&#x25BA; This can be customized by use of a user-supplied result document resolver.
454
                  By default, result documents are serialized to files in filestore, which implies that the URIs must
455
                  use the <code>file</code> URI scheme.</p>
456
            </li>
457
         </ol>
458
      </div>
459
      
460
      <div class="div2">
461
         <h3>
462
            <i>F.2 Vendor and User Extensions</i>
463
         </h3>
464
         <p>
465
            <i>This category covers extensions and extensibility: mechanisms for providing vendor or
466
               user extensions to the language without sacrificing interoperability.</i>
467
         </p>
468
         <p>
469
            <i>In general terms, it is implementation-defined:</i>
470
         </p>
471
         <ul>
472
            <li>
473
               <p>
474
                  <i>whether and under what circumstances the implementation recognizes any
475
                     extension functions, extension instructions, extension attributes, user-defined
476
                     data elements, additional types, additional serialization methods or
477
                     serialization parameters, or additional collations, and if so, what effect they
478
                     have.</i>
479
               </p>
480
               <p>&#x25BA; Extensions implemented by the Saxon processor are documented at
481
                  <a class="bodylink" href="/extensions">Extensions</a>.</p>
482
            </li>
483
            <li>
484
               <p>
485
                  <i>whether, how, and under what circumstances the implementation allows users to
486
                     define extension functions, extension instructions, extension attributes,
487
                     user-defined data elements, additional types, additional serialization methods
488
                     or serialization parameters, or additional collations. If it does allow users
489
                     to do so, it must follow the rules given elsewhere in this specification.</i>
490
               </p>
491
               <p>&#x25BA; Mechanisms provided by the Saxon processor for implementing extension functions
492
                  and extension instructions are documented at <a class="bodylink"
493
                     href="/extensions">Extensibility Mechanisms</a>.
494
                  Mechanisms for extending the serialization capability are available via the method
495
                  <code>Configuration.setSerializerFactory()</code>. Collations can be defined at
496
                  configuration level either by registering individual collations using <code>Configuration.registerCollation()</code>,
497
                  or by supplying a user-written <code>CollationURIResolver</code>.
498
               </p>
499
            </li>
500
            <li>
501
               <p>
502
                  <i>what information is available to such extensions (for example, whether they
503
                     have access to the static and dynamic context.)</i>
504
               </p>
505
               <p>&#x25BA; Some of the mechanisms for implementing extension instructions and extension functions
506
                  provide the implementation of the instruction or function with information about the static and
507
                  dynamic context.</p>
508
            </li>
509
            <li>
510
               <p>
511
                  <i>where such extensions are allowed, the extent to which the processor enforces
512
                     their correct behaviour (for example, checking that strings returned by
513
                     extension functions contain only valid XML characters)</i>
514
               </p>
515
               <p>&#x25BA; By default the results of extensions are checked, but the implementation
516
                  of an extension can assert that the result is to be trusted.</p>
517
            </li>
518
         </ul>
519
         <p>
520
            <i>More specifically:</i>
521
         </p>
522
         <ol>
523
            <li>
524
               <p>
525
                  <i>The mechanisms for creating new extension instructions and extension functions
526
                     are implementation-defined. It is not <span class="verb">required</span> that
527
                     implementations provide any such mechanism. (See 2.8 Extensibility)</i>
528
               </p>
529
               <p>&#x25BA; Mechanisms provided by the Saxon processor for implementing extension functions
530
                  and extension instructions are documented at <a class="bodylink"
531
                     href="/extensions">Extensibility Mechanisms</a>.</p>
532
            </li>
533
            <li>
534
               <p>
535
                  <i>The set of namespaces that are specially recognized by the implementation (for
536
                     example, for user-defined data elements, and extension attributes) is
537
                     implementation-defined. (See 3.7.3 User-defined Data Elements)</i>
538
               </p>
539
               <p>&#x25BA; Saxon recognizes the namespace <code>http://saxon.sf.net/</code> for its own extensions;
540
                  it also recognizes extensions in various namespaces defined by the <code>EXSLT</code> and <code>EXPath</code>
541
                  communities.</p>
542
            </li>
543
            <li>
544
               <p>
545
                  <i>The effect of user-defined data elements whose name is in a namespace
546
                     recognized by the implementation is implementation-defined. (See 3.7.3
547
                     User-defined Data Elements)</i>
548
               </p>
549
               <p>&#x25BA; Saxon only recognizes user-defined data elements in the namespace <code>http://saxon.sf.net/</code>.
550
                  Any other user-defined data elements are ignored.</p>
551
            </li>
552
            <li>
553
               <p>
554
                  <i>An implementation may define mechanisms, above and beyond
555
                        <code>xsl:import-schema</code>, that allow schema components such as type
556
                     definitions to be made available within a stylesheet. (See 3.14 Built-in
557
                     Types)</i>
558
               </p>
559
               <p>&#x25BA; Saxon allows schemas to be loaded into the configuration in a number of ways, but type definitions
560
                  can generally be used in a stylesheet only if the namespace is explicitly imported using <code>xsl:import-schema</code>.
561
               The exception is types corresponding to external Java objects: every Java class on the classpath has a corresponding
562
               named external type definition which is implicitly imported.</p>
563
               <p>&#x25BA; If syntax extensions are enabled, Saxon allows union types to be defined inline using syntax such as
564
               <code>union(xs:date, xs:dateTime)</code> anywhere that an <code>ItemType</code> is expected.</p>
565
            </li>
566
            <li>
567
               <p>
568
                  <i>The set of extension functions available in the static context for the target
569
                     expression of <code>xsl:evaluate</code> is implementation-defined. (See 10.4.1
570
                     Static context for the target expression)</i>
571
               </p>
572
               <p>&#x25BA; All extension functions available within a stylesheet are also available in XPath expressions
573
                  dynamically evaluated using <code>xsl:evaluate</code>.</p>
574
            </li>
575
            <li>
576
               <p>
577
                  <i>If the <code>data-type</code> attribute of the <code>xsl:sort</code> element
578
                     has a value other than <code>text</code> or <code>number</code>, the effect is
579
                     implementation-defined. (See 13.1.2 Comparing Sort Key Values)</i>
580
               </p>
581
               <p>&#x25BA; No additional values are recognised.</p>
582
            </li>
583
            <li>
584
               <p>
585
                  <i>The posture and sweep of extension functions (and references to extension
586
                     functions) and extension instructions are implementation-defined. (See 19.8.4.2
587
                     Streamability of extension instructions)</i>
588
               </p>
589
               <p>&#x25BA; Extension functions and instructions are not streamable, with the exception of
590
                  the <code>saxon:stream()</code> extension function.</p>
591
            </li>
592
            <li>
593
               <p>
594
                  <i>Additional streamability categories for stylesheet functions may be defined by
595
                     an implementation. (See 19.8.5 Classifying Stylesheet Functions)</i>
596
               </p>
597
               <p>&#x25BA; No additional categories are recognized for streamable stylesheet functions.</p>
598
            </li>
599
            <li>
600
               <p>
601
                  <i>The effect of an extension function returning a string containing characters
602
                     that are not permitted in XML is implementation-defined. (See 24.1.2 Calling
603
                     Extension Functions)</i>
604
               </p>
605
               <p>&#x25BA; The results are not checked.</p>
606
            </li>
607
            <li>
608
               <p>
609
                  <i>The way in which external objects are represented in the type system is
610
                     implementation-defined. (See 24.1.3 External Objects)</i>
611
               </p>
612
               <p>&#x25BA; In addition to nodes, atomic values, and functions, Saxon supports a fourth
613
                  kind of item: the external Java (or .NET) object. The value of such an item is simply
614
                  a wrapper for the external object. These have types which correspond
615
                  to the Java or .NET class hierarchy.</p>
616
            </li>
617
         </ol>
618
      </div>
619
      <div class="div2">
620
         <h3>
621
            <i>F.3 Localization</i>
622
         </h3>
623
         <p>
624
            <i>This specification, and the specifications that it refers to, include facilities for
625
               adapting the output of a transformation to meet local expectations: examples include
626
               the formatting of numbers and dates, and the choice of collations for sorted output.
627
               The general principles are:</i>
628
         </p>
629
         <ul>
630
            <li>
631
               <p>
632
                  <i>The specification does not mandate any particular localizations that processors
633
                     must offer: for example, a conformant processor might choose to provide output
634
                     in Japanese only.</i>
635
               </p>
636
            </li>
637
            <li>
638
               <p>
639
                  <i>The specification provides fallback mechanisms so that if a particular
640
                     localization is requested and is not available, processing does not fail.</i>
641
               </p>
642
            </li>
643
         </ul>
644
         <p>
645
            <i>More specifically:</i>
646
         </p>
647
         <ol>
648
            <li>
649
               <p>
650
                  <i>The combinations of languages and numbering sequences recognized by the
651
                        <code>xsl:number</code> instruction, beyond those defined as mandatory in
652
                     this specification, are implementation-defined. There <span class="verb"
653
                        >may</span> be implementation-defined upper bounds on the numbers that can
654
                     be formatted using any particular numbering sequence. There <span class="verb"
655
                        >may</span> be constraints on the values of the <code>ordinal</code>
656
                     attribute recognized for any given language. (See 12.4 Number to String
657
                     Conversion Attributes)</i>
658
               </p>
659
               <p>&#x25BA; Saxon uses the ICU-J library for localization. This offers a large and
660
               extensible set of languages. The numbering sequences recognized are listed
661
               at <a class="bodylink" href="/xsl-elements/number">xsl:number</a>.</p>
662
            </li>
663
            <li>
664
               <p>
665
                  <i>The facilities for defining collations and allocating URIs to identify them are
666
                     largely implementation-defined. (See 13.1.3 Sorting Using Collations)</i>
667
               </p>
668
               <p>&#x25BA; Mechanisms provided by the Saxon processor for implementing extension functions
669
                  and extension instructions are documented at <a class="bodylink"
670
                     href="/extensions">Extensibility Mechanisms</a>.
671
                  Mechanisms for extending the serialization capability are available via the method
672
                  <code>Configuration.setSerializerFactory()</code>. Collations can be defined at
673
                  configuration level either by registering individual collations using <code>Configuration.registerCollation()</code>,
674
                  or by supplying a user-written <code>CollationURIResolver</code>.
675
               </p>
676
            </li>
677
            <li>
678
               <p>
679
                  <i>The algorithm used by <code>xsl:sort</code> to locate a collation, given the
680
                     values of the <code>lang</code> and <code>case-order</code> attributes, is
681
                     implementation-defined. (See 13.1.3 Sorting Using Collations)</i>
682
               </p>
683
               <p>&#x25BA; If these attributes are present then the Unicode Collation Algorithm is used,
684
                  selected by a collation URI that incorporates these two parameters.</p>
685
            </li>
686
            <li>
687
               <p>
688
                  <i>If none of the <code>collation</code>, <code>lang</code>, or
689
                        <code>case-order</code> attributes is present (on <code>xsl:sort</code>),
690
                     the collation is chosen in an implementation-defined way. (See 13.1.3 Sorting
691
                     Using Collations)</i>
692
               </p>
693
               <p>&#x25BA; By default, Unicode codepoint collation is used.</p>
694
            </li>
695
            <li>
696
               <p>
697
                  <i>When using the family of URIs that invoke the Unicode Collation Algorithm, the
698
                     effect of supplying a query keyword or value not defined in this specification
699
                     is implementation-defined. The defaults for query keywords are also
700
                     implementation-defined unless otherwise stated. (See 13.4 The Unicode Collation
701
                     Algorithm)</i>
702
               </p>
703
               <p>&#x25BA; By default, unrecognized parameters are ignored.</p>
704
            </li>
705
         </ol>
706
      </div>
707
      <div class="div2">
708
         <h3>
709
            <i>F.4 Optional Features</i>
710
         </h3>
711
         <p>
712
            <i>As well as the optional conformance features identified in <i>27 Conformance</i>,
713
               some specific features of the specification are defined to be optional.</i>
714
         </p>
715
         <ol>
716
            <li>
717
               <p>
718
                  <i>It is implementation-defined whether an <span>XSLT 3.0</span> processor
719
                     supports backwards compatible behaviour for any XSLT version earlier than XSLT
720
                     3.0. (See 3.9 Backwards Compatible Processing)</i>
721
               </p>
722
               <p>&#x25BA; XSLT 1.0 and XSLT 2.0 backwards compatibility are supported as defined in the W3C specification,
723
               in Saxon-HE from 9.8.0.7, or for earlier versions of 9.8 in Saxon-PE and Saxon-EE only.</p>
724
            </li>
725
            <li>
726
               <p>
727
                  <i>If an <code>xml:id</code> attribute that has not been subjected to attribute
728
                     value normalization is copied from a source tree to a result tree, it is
729
                     implementation-defined whether attribute value normalization will be applied
730
                     during the copy process. (See 11.9.1 Shallow Copy)</i>
731
               </p>
732
               <p>&#x25BA; Attribute value normalization is applied.</p>
733
            </li>
734
            <li>
735
               <p>
736
                  <i>It is implementation-defined whether, and under what circumstances, disabling
737
                     output escaping is supported. (See 26.2 Disabling Output Escaping)</i>
738
               </p>
739
               <p>&#x25BA; Disable-output-escaping is supported provided that the result tree is being serialized,
740
                  and that no <code>xsl:try</code> or <code>xsl:fork</code> instruction is in effect.</p>
741
            </li>
742
         </ol>
743
      </div>
744
      <div class="div2">
745
         <h3>
746
            <i>F.5 Dependencies</i>
747
         </h3>
748
         <p>
749
            <i>When this specification refers normatively to other specifications, it generally
750
               gives implementations freedom to decide (within constraints) which version of the
751
               referenced specification should be used. Specifically:</i>
752
         </p>
753
         <ol>
754
            <li>
755
               <p>
756
                  <i>It is implementation-defined which versions and editions of XML and XML
757
                     Namespaces (1.0 and/or 1.1) are supported. (See 4.1 XML Versions)</i>
758
               </p>
759
               <p>&#x25BA; Both 1.0 and 1.1 are supported provided support is available from the chosen XML parser.
760
               XML 1.1 is available only if explicitly requested.</p>
761
            </li>
762
            <li>
763
               <p>
764
                  <i>It is implementation-defined which versions of XML, HTML, and XHTML are
765
                     supported in the <code>version</code> attribute of the <code>xsl:output</code>
766
                     declaration. (See 26 Serialization)</i>
767
               </p>
768
               <p>&#x25BA; XML 1.0 and 1.1 are supported; HTML 4 and 5 are supported; XHTML 1 and 5 are supported.</p>
769
            </li>
770
            <li>
771
               <p>
772
                  <i>It is implementation-defined whether (and if so how) an XSLT 3.0 processor is
773
                     able to work with versions of XPath later than XPath 3.1. (See 27
774
                     Conformance)</i>
775
               </p>
776
               <p>&#x25BA; The question does not yet arise.</p>
777
            </li>
778
            <li>
779
               <p>
780
                  <i>It is implementation-defined whether (and if so how) an XSLT 3.0 processor is
781
                     able to work with versions of [XSLT and XQuery Serialization] later than 3.1.
782
                     (See 27.3 Serialization Feature)</i>
783
               </p>
784
               <p>&#x25BA; The question does not yet arise.</p>
785
            </li>
786
         </ol>
787
      </div>
788
      <div class="div2">
789
         <h3>
790
            <i>F.6 Defaults and Limits</i>
791
         </h3>
792
         <p>
793
            <i>To accommodate variations in the way that the XSLT language is deployed, and the
794
               constraints of different processing environments, defaults for some options are
795
               implementation-defined. In addition, limits on the sizes of ranges of values
796
               permitted are in general implementation-defined:</i>
797
         </p>
798
         <ol>
799
            <li>
800
               <p>
801
                  <i>Limits on the value space of primitive datatypes, where not fixed by [XML
802
                     Schema Part 2], are implementation-defined. (See 4.8 Limits)</i>
803
               </p>
804
               <p>&#x25BA; For integers, decimals, and strings, the only limits imposed by Saxon are those inherent
805
                  in the underlying Java types <code>BigInteger</code>, <code>BigDecimal</code>, and <code>String</code>. </p>
806
                  <p>For calendar data types, the year 
807
                  must be in the range of a signed 32-bit integer; seconds are supported to a
808
                  fractional precision of nine digits (that is, nanosecond precision). </p>
809
                  <p>For durations, the number of months must fit in a 
810
                  signed 32-bit integer; the integer number of seconds must fit in a signed 64-bit integer, and the 
811
                  precision is to nanoseconds.</p>
812
                  <p>The maximum length of a sequence (or array) is limited to 2<sup>31</sup>-1 items.</p>
813
            </li>
814
            <li>
815
               <p>
816
                  <i>The default value of the <code>encoding</code> attribute of the
817
                        <code>xsl:output</code> element is implementation-defined. Where the
818
                     encoding is UTF-8, the default for the <code>byte-order-mark</code> attribute
819
                     is implementation-defined. (See 26 Serialization)</i>
820
               </p>
821
               <p>&#x25BA; The default encoding is UTF-8; by default, no byte order mark is written.</p>
822
            </li>
823
         </ol>
824
      </div>
825
      
826
      <div class="div2">
827
         <h3>
828
            <i>F.7 Detection and Reporting of Errors</i>
829
         </h3>
830
         <p>
831
            <i>Some aspects of error handling are implementation-defined:</i>
832
         </p>
833
         <ol>
834
            <li>
835
               <p>
836
                  <i>It is implementation-defined whether type errors are signaled statically. (See
837
                     2.12 Error Handling)</i>
838
               </p>
839
               <p>&#x25BA; Type errors are signaled statically where the intersection of the required type
840
                  and the (statically-inferred) supplied type is empty.</p>
841
            </li>
842
            <li>
843
               <p>
844
                  <i>If the effective version of any element in the stylesheet is not 1.0 or 2.0 but
845
                     is less than 3.0, the <span class="verb">recommended</span> action is to report
846
                     a static error; however, processors <span class="verb">may</span> recognize
847
                     such values and process the element in an implementation-defined way. (See 3.9
848
                     Backwards Compatible Processing)</i>
849
               </p>
850
               <p>&#x25BA; Saxon reports a warning and treats the value as 2.0.</p>
851
            </li>
852
            <li>
853
               <p>
854
                  <i>The default values for the <code>warning-on-no-match</code> and
855
                        <code>warning-on-multiple-match</code> attributes of <code>xsl:mode</code>
856
                     are implementation-defined. (See 6.6.1 Declaring Modes)</i>
857
               </p>
858
               <p>&#x25BA; The default values are <code>no</code> and <code>yes</code> respectively.</p>
859
            </li>
860
            <li>
861
               <p>
862
                  <i>The form of any warnings output when there is no matching template rule, or
863
                     when there are multiple matching template rules, is implementation-defined.
864
                     (See 6.6.1 Declaring Modes)</i>
865
               </p>
866
               <p>&#x25BA; The warning, by default, consists of an explanatory English-language message
867
                  sent to the system error output; both the form of the message and its destination may
868
                  be customized.</p>
869
            </li>
870
            <li>
871
               <p>
872
                  <i>The destination and formatting of messages written using the
873
                        <code>xsl:message</code> instruction are implementation-defined. (See 23.1
874
                     Messages)</i>
875
               </p>
876
               <p>&#x25BA; By default messages are serialized as XML and 
877
                  sent to the system error output; both the form of the message and its destination may
878
                  be customized.</p>
879
            </li>
880
         </ol>
881
      </div>
882

    
883
      
884

    
885
   </section>
886
   <section id="xpath20" title="XPath 2.0 conformance">
887
      <h1>XPath 2.0 conformance</h1>
888

    
889

    
890
      <p>Saxon for many years has implemented the full XPath 2.0 language as defined in the Second
891
         Edition <a href="http://www.w3.org/TR/xpath20/" class="bodylink">Recommendation</a> of 14
892
         December 2010.</p>
893
      
894
      <p>Recent Saxon releases focus primarily on XPath 3.1 support, and deliver XPath 2.0 when required by restricting some of the
895
         capabilities of the XPath 3.1 processor. For example, this is the default for XPath expressions appearing
896
         within assertions or conditional type alternatives in XSD 1.1 schemas. In particular,</p>
897
     
898
      
899
      <ul>
900
         <li><p>During parsing of the XPath expression, new syntatic constructs are disallowed. These include:</p>
901
         <ul>
902
            <li>Let expressions</li>
903
            <li>Inline functions, dynamic function calls, function literals, and partially-applied functions</li>
904
            <li>New operators: <code>||</code>, <code>!</code>, <code>?</code>, <code>=></code></li>
905
            <li>Map and array constructor expressions</li>
906
            <li>EQNames in the format <code>Q{uri}local</code></li>
907
         </ul></li>
908
         <li><p>Functions in the standard function library are added to the static context only if they were available in XPath 2.0</p></li>
909
      </ul>
910
      
911
      <p>Saxon-EE 9.9 passes 15238 out of 15242 XPath 2.0 tests in the W3C test suite. The failures occur in cases where XPath 3.1 relaxes the rules
912
      and it is not practical or sensible for Saxon to enforce several different sets of constraints. In particular:</p>
913

    
914
      <ul>
915
         <li>XPath 2.0 only allowed casting of a string to a QName if the string was written as a literal. This restriction was always
916
         difficult to enforce because it straddles the boundaries between the lexical and semantic parts of the compiler, and it also serves
917
         very little purpose, so Saxon no longer enforces it.</li>
918
         <li>XPath 2.0 required the first argument to <code>fn:string-join</code> to be of type <code>xs:string*</code>, while XPath 3.1
919
         allows <code>xs:anyAtomicType*</code>, and casts the supplied values to strings.</li>
920
         <li>XPath 3.1 extends what is allowed in the picture string of <code>fn:format-number()</code>.</li>
921
      </ul>
922
      
923
      <p>The general rule is that when Saxon acts as an XPath 2.0 processor, all correct (non-error) inputs produce a conformant result,
924
      but a small number of error cases are not detected.</p>
925
      
926
      <p>There are also a few situations where XPath 3.1 chose to introduce incompatible changes. For example, <code>fn:format-time()</code>
927
      was changed in 3.1 to truncate the fractional seconds value rather than rounding it. In such cases Saxon follows the XPath 3.1 rules,
928
      since the change was made for good reasons.</p>
929
      
930

    
931

    
932
   </section>
933

    
934
   
935
   <section id="xpath31" title="XPath 3.1 Conformance">
936
      <h1>XPath 3.1 Conformance</h1>
937

    
938
      <p>Saxon 10 implements the final XPath 3.1 Recommendation in its entirety.</p>
939
      
940
      <p>At the time of release Saxon-EE 10.0 passes all 22049 applicable tests in the W3C XPath/XQuery test suite (QT3). Tests are run on both
941
         the Java and .NET platforms.
942
      </p>
943
      
944
      <p>Although the W3C XQuery Working Group has ceased operation, the W3C QT3 test suite continues to be developed by
945
         volunteers, and Saxonica remains an active contributor. The test suite can be found at 
946
         <a href="https://github.com/w3c/qt3tests" class="bodylink">https://github.com/w3c/qt3tests</a>.
947
         Tests are labeled to indicate which specifications (XPath/XQuery) and versions they apply to.
948
         Conformance issues raised by Saxon users typically
949
         result in new test cases being added to the test suite.</p>
950
      
951
      <p>New features that were introduced in XPath 3.0 include the following:</p>
952
      
953
      <ul>
954
         <li>
955
            <p>String contatenation operator <code>||</code></p>
956
         </li>
957
         <li>
958
            <p>Simple mapping operator <code>!</code></p>
959
         </li>
960
         <li>
961
            <p>Casting is allowed from a string to a union or list type</p>
962
         </li>
963
         <li>
964
            <p>Union types, provided they meet certain rules, can be used as a
965
               <code>SequenceType</code></p>
966
         </li>
967
         <li>
968
            <p>Higher order functions, including:</p>
969
            <ul>
970
               <li>Inline functions, for example <code>function($i) {$i*$i}</code></li>
971
               <li>Dynamic function calls</li>
972
               <li>Function literals, for example <code>substring#2</code></li>
973
               <li>Partial function application, for example <code>concat('$', ?)</code></li>
974
            </ul>
975
         </li>
976

    
977
         <li>
978
            <p>Let expressions, for example <code>let $v := expr return f($v)</code></p>
979
         </li>
980
         <li>
981
            <p>EQNames (<code>Q{uri}local</code>) wherever QNames are allowed</p>
982
         </li>
983
      </ul>
984

    
985
      <p>XPath 3.1 added:</p>
986

    
987
      <ul>
988
         <li>
989
            <p>Support for maps and arrays</p>
990
         </li>
991
         <li>
992
            <p>Functions to read and write data in JSON format</p>
993
         </li>
994
         <li>
995
            <p>A new operator (<code>=></code>) to allow function chaining</p>
996
         </li>
997
         <li>
998
            <p>Various new functions including <code>random-number-generator()</code>,
999
                  <code>sort()</code>, <code>parse-ietf-date()</code>.</p>
1000
         </li>
1001
      </ul>
1002
      
1003
      
1004
      
1005
      <h2 class="subtitle">Implementation-defined aspects of Functions and Operators</h2>
1006
      
1007
      <p>The Functions and Operators specification includes a number of implementation-defined
1008
         behaviors. This section describes how these are implemented in Saxon.</p>
1009
      <ol>
1010
         <li>
1011
            
1012
            <p>
1013
               <i>The destination of the trace for <code>fn:trace()</code> output is
1014
                  implementation-defined. </i>
1015
            </p>
1016
            
1017
            <p>&#x25BA; By default trace output is sent to the standard error output. It can be redirected in
1018
               various ways: by redirecting <code>System.err</code>, by supplying a user-written
1019
               <code>MessageEmitter</code>, or by changing the output destination of the standard
1020
               <code>MessageEmitter</code> to a defined output stream or writer.</p>
1021
         </li>
1022
         <li>
1023
            
1024
            <p>
1025
               <i>For [overflow during] <code>xs:integer</code> operations, implementations that
1026
                  support limited-precision integer operations must either raise an error
1027
                  [err:FOAR0002] or provide an implementation-defined mechanism that allows users to
1028
                  choose between raising an error and returning a result that is modulo the largest
1029
                  representable integer value.</i>
1030
            </p>
1031
            
1032
            <p>&#x25BA; Saxon supports unlimited-precision integer arithmetic, so this provision does not
1033
               apply.</p>
1034
         </li>
1035
         <li>
1036
            
1037
            <p>
1038
               <i>For <code>xs:decimal</code> values the number of digits of precision returned by
1039
                  the numeric operators is implementation-defined. If the number of digits in the
1040
                  result exceeds the number of digits that the implementation supports, the result
1041
                  is truncated or rounded in an implementation-defined manner. </i>
1042
            </p>
1043
            
1044
            <p>&#x25BA; Saxon supports unlimited-precision decimal arithmetic. For addition, subtraction, and
1045
               multiplication, no rounding or truncation occurs; the full precision of the result is
1046
               maintained. For division, the number of digits in the result is: the number of digits
1047
               in the numerator, the number of digits in the divisor, or 18, whichever is greatest.
1048
               Rounding of values in the range .0 to .5 inclusive is towards zero, otherwise away
1049
               from zero.</p>
1050
         </li>
1051
         <li>
1052
            
1053
            <p>
1054
               <i>It is implementation-defined which version of Unicode is supported by the features
1055
                  defined in this specification, but it is recommended that the most recent version
1056
                  of Unicode be used. </i>
1057
            </p>
1058
            
1059
            <p>&#x25BA; For the <dfn>Unicode</dfn> character categories used in regular expressions, Saxon
1060
               (since release 9.4) uses the tables from Unicode 6.0.0. For Unicode blocks in regular
1061
               expressions, Saxon uses the definitions in Unicode 6.0.0, but also supports block
1062
               names (such as "Greek") from earlier Unicode versions where the blocks have since
1063
               been renamed.</p>
1064
            
1065
            <p>Some functions such as the implementations of <code>upper-case()</code> and
1066
               <code>lower-case()</code> are delegated to the Java VM, and the result therefore
1067
               depends on the Unicode version supported by the Java VM. In JDK 5.0 this is Unicode
1068
               version 4.0. </p>
1069
            
1070
            <p>Other functions such as <code>normalize-unicode()</code> are implemented natively
1071
               within Saxon. The character tables used for this are derived from the Unicode 4.0
1072
               database.</p>
1073
         </li>
1074
         <li>
1075
            
1076
            <p>
1077
               <i>For <code>normalize-unicode()</code>, conforming implementations must support
1078
                  normalization form "NFC" and may support normalization forms "NFD", "NFKC",
1079
                  "NFKD", "FULLY-NORMALIZED". They may also support other normalization forms with
1080
                  implementation-defined semantics. </i>
1081
            </p>
1082
            
1083
            <p>&#x25BA; Saxon currently supports normalization forms NFC, NFD, NFKC, and NFKD.</p>
1084
         </li>
1085
         <li>
1086
            
1087
            <p>
1088
               <i>The ability to decompose strings into <dfn>collation units</dfn> suitable for
1089
                  substring matching is an implementation-defined property of a collation.</i>
1090
            </p>
1091
            
1092
            <p>&#x25BA; Saxon supports this capability for a collation implemented using a Java
1093
               <code>RuleBasedCollator</code>. Any Java <code>Comparator</code> can be used to
1094
               implement a collation, but the substring matching functions will fail (error
1095
               FOCH0004) if the <code>Comparator</code> is not a <code>RuleBasedCollator</code>.</p>
1096
            
1097
            <p>Saxon also supports this capability on the .NET platform. However, the results
1098
               delivered by the collation support on the .NET platform do not appear to be 100%
1099
               aligned with the XPath specification.</p>
1100
         </li>
1101
         <li>
1102
            
1103
            <p>
1104
               <i>All minimally conforming processors must support year values with a minimum of 4
1105
                  digits (i.e., YYYY) and a minimum fractional second precision of 1 millisecond or
1106
                  three digits (that is, s.sss). However, conforming processors may set larger
1107
                  implementation-defined limits on the maximum number of digits they support in
1108
                  these two situations.</i>
1109
            </p>
1110
            
1111
            <p>&#x25BA; Saxon allows the year to be any 32-bit signed integer. The interpretation of negative
1112
               years depends on whether the system is configured to use XSD 1.0 or XSD 1.1 semantics
1113
               (in XSD 1.1, year zero exists, in XSD 1.0 it does not). Seconds are supported to a
1114
               fractional precision of six digits (that is, microsecond precision).</p>
1115
         </li>
1116
         <li>
1117
            
1118
            <p>
1119
               <i>Various aspects of the processing provided by <code>doc()</code> are
1120
                  implementation-defined. Implementations may provide external configuration options
1121
                  that allow any aspect of the processing to be controlled by the user.</i>
1122
            </p>
1123
            
1124
            <p>&#x25BA; Saxon allows the URI dereferencing to be performed using a user-supplied
1125
               <code>URIResolver</code>, as defined in the JAXP specification, or using an
1126
               <code>XmlResolver</code> on the .NET platform. Saxon also provides various options
1127
               to control whitespace stripping, validation using a DTD or schema, handling of
1128
               errors, and support for XML 1.1. If appropriate configuration options are set, then
1129
               query parameters are recognized in the URI to control some of these decisions.</p>
1130
         </li>
1131
      </ol>
1132
   </section>
1133

    
1134
   <!--<section id="xquery" title="XQuery 1.0 Conformance">
1135
      <h1>XQuery 1.0 Conformance</h1>
1136

1137

1138
      <p>This release of Saxon implements the full XQuery 1.0 language as defined in the Second
1139
         Edition <a href="http://www.w3.org/TR/xquery/" class="bodylink">Recommendation</a> of 14
1140
         December 2010. The <a class="bodylink" href="../xpath20">restrictions</a> noted with
1141
         respect to XPath 2.0 apply equally to Saxon's support for XQuery 1.0.</p>
1142

1143
      <p>XQuery conformance levels are described in <a
1144
            href="http://www.w3.org/TR/xquery/#id-xquery-conformance" class="bodylink">Section 5 of
1145
            the XQuery specification</a>.</p>
1146

1147
      <p>Saxon-HE and Saxon-PE provide <strong>Minimal Conformance</strong> plus the following
1148
            <strong>Optional Features</strong>:</p>
1149
      <ul>
1150
         <li>
1151
            <p>Full Axis Feature</p>
1152
         </li>
1153
         <li>
1154
            <p>Module Feature</p>
1155
         </li>
1156
         <li>
1157
            <p>Serialization Feature</p>
1158
         </li>
1159
      </ul>
1160

1161
      <p>Saxon-EE provides <strong>Minimal Conformance</strong> plus the following <strong>Optional
1162
            Features</strong>:</p>
1163
      <ul>
1164
         <li>
1165
            <p>Schema Import Feature</p>
1166
         </li>
1167
         <li>
1168
            <p>Schema Validation Feature</p>
1169
         </li>
1170
         <li>
1171
            <p>Full Axis Feature</p>
1172
         </li>
1173
         <li>
1174
            <p>Module Feature</p>
1175
         </li>
1176
         <li>
1177
            <p>Serialization Feature</p>
1178
         </li>
1179
      </ul>
1180

1181
      <p>None of the Saxon products supports the Static Typing Feature, and there are no plans to do
1182
         so.</p>
1183

1184
      <p>There are some known non-conformances if the product is used in particular ways:</p>
1185
      <ul>
1186
         <li>
1187
            <p>In pull mode (<code>-pull</code> on the command line) there is a restriction that
1188
               namespace undeclaration is not supported; this means that the query prolog option
1189
                  <code>copy-namespaces no-inherit</code> has no effect.</p>
1190
         </li>
1191
         <li>
1192
            <p>Under .NET, if the <code>System.Xml</code> parser is selected, attributes declared in
1193
               the DTD as being of type <code>ID</code> are not accessible using the
1194
                  <code>id()</code> function. This is because the <code>System.Xml</code> parser
1195
               does not make the DTD-defined attribute type available to the application. </p>
1196
         </li>
1197

1198
      </ul>
1199
      <h2 class="subtitle">Conformance Tests</h2>
1200

1201
      <p>Saxonica has submitted results for the published <a
1202
            href="http://www.w3.org/XML/Query/test-suite/" class="bodylink">W3C XQuery Test
1203
            suite</a>. W3C has published both <a
1204
            href="http://www.w3.org/XML/Query/test-suite/XQTSReportSimple.html" class="bodylink"
1205
            >summary</a> and <a href="http://www.w3.org/XML/Query/test-suite/XQTSReport.html"
1206
            class="bodylink">detail</a> reports from the results; at the time of submission Saxon-EE
1207
         was the only product to achieve a 100% pass rate.</p>
1208

1209
      <p>The test driver used to measure these results is included in the Saxon distribution as part
1210
         of the <code>saxon-resources-9.n</code> download.</p>
1211
      <h2 class="subtitle">Checklist of Implementation-Defined Items</h2>
1212

1213
      <p>Appendix D of the XQuery specification lists a number of features whose behaviour is
1214
         implementation-defined. For Saxon, the behaviour is as follows:</p>
1215
      <ol>
1216
         <li>
1217

1218
            <p>
1219
               <i>The version of Unicode that is used to construct expressions.</i>
1220
            </p>
1221

1222
            <p>&#x25BA; For details of Saxon Unicode support, see <a class="bodylink" href="../xslt20">XSLT
1223
                  2.0 Conformance.</a></p>
1224
         </li>
1225
         <li>
1226

1227
            <p>
1228
               <i>The statically-known collations.</i>
1229
            </p>
1230

1231
            <p>&#x25BA; Collation URIs of the form
1232
                     <code>http://saxon.sf.net/collation?<i>param=value;param=value...</i></code>
1233
               are always available: these map to the collations offered by the locales available
1234
               within the Java VM in use. Additional collation URIs may be implemented by users and
1235
               registered with the Saxon configuration via the Java API.</p>
1236
         </li>
1237
         <li>
1238

1239
            <p>
1240
               <i>The implicit timezone.</i>
1241
            </p>
1242

1243
            <p>&#x25BA; The implicit timezone is normally taken from the system clock. This may, however, be
1244
               overridden via the Java API.</p>
1245
         </li>
1246
         <li>
1247

1248
            <p>
1249
               <i>The circumstances in which warnings are raised, and the ways in which warnings are
1250
                  handled.</i>
1251
            </p>
1252

1253
            <p>&#x25BA; Warnings are raised for a variety of conditions. Compile time warnings include:</p>
1254
            <ul>
1255
               <li>
1256
                  <p>Use of a path expression that can never select anything (for example
1257
                        <code>@a/@b</code>)</p>
1258
               </li>
1259
               <li>
1260
                  <p>Use of an expression that can only succeed if one or more operands are empty
1261
                     sequences</p>
1262
               </li>
1263
               <li>
1264
                  <p>Use of a string literal in a PITest that is not a valid NCName</p>
1265
               </li>
1266
            </ul>
1267

1268
            <p>Warnings may also be raised at run-time, for example if the <code>collection()</code>
1269
               function fails to load a document and recovery has been requested.</p>
1270

1271
            <p>Compile-time warnings are sent to the JAXP <code>ErrorListener</code> registered with
1272
               the <code>Configuration</code>; the default <code>ErrorListener</code> displays them
1273
               as messages on <code>System.err</code>. Run-time warnings are sent to the JAXP
1274
                  <code>ErrorListener</code> registered with the <code>Controller</code>; the
1275
               default is the same.</p>
1276
         </li>
1277
         <li>
1278

1279
            <p>
1280
               <i>The method by which errors are reported to the external processing
1281
                  environment.</i>
1282
            </p>
1283

1284
            <p>&#x25BA; Compile-time errors are sent to the JAXP <code>ErrorListener</code> registered with
1285
               the <code>Configuration</code>; the default <code>ErrorListener</code> displays them
1286
               as messages on <code>System.err</code>. Run-time errors are sent to the JAXP
1287
                  <code>ErrorListener</code> registered with the <code>Controller</code>; the
1288
               default is the same. When queries are invoked from a Java application, any error will
1289
               also be notified by throwing an exception.</p>
1290
         </li>
1291
         <li>
1292

1293
            <p>
1294
               <i>Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or
1295
                  the rules of [XML 1.1] and [XML Names 1.1]. One of these sets of rules must be
1296
                  applied consistently by all aspects of the implementation.</i>
1297
            </p>
1298

1299
            <p>&#x25BA; Saxon gives the user the choice: see <a class="bodylink" href="/sourcedocs/xml11"
1300
                  >Saxon and XML 1.1</a>. Note that since Saxon allows the user to select which XML
1301
               parser to use on a per-document basis, achievement of consistency across "all aspects
1302
               of the implementation" is in part a user responsibility. Saxon will not reject any
1303
               attempt to use an XML 1.1 parser in a 1.0 configuration, or vice versa.</p>
1304

1305
            <p>Since Saxon 9.4, all operations in Saxon itself (as distinct from the underlying
1306
               parser) that depend on the rules for XML Names use the rules that are defined in XML
1307
               1.0 fifth edition and in XML 1.1, rather than the rules defined in earlier XML 1.0
1308
               editions.</p>
1309

1310

1311
         </li>
1312
         <li>
1313

1314
            <p>
1315
               <i>Any components of the static context or dynamic context that are overwritten or
1316
                  augmented by the implementation.</i>
1317
            </p>
1318

1319
            <p>&#x25BA; The following table shows the components of the static context. For each component,
1320
               the second column shows whether the component is overwritten or augmented by Saxon
1321
               itself. The third column shows whether it may be overwritten or augmented by an
1322
               application, through facilities in the Java API.</p>
1323
            <table>
1324
               <thead>
1325
                  <tr>
1326
                     <td>
1327
                        <p>Component</p>
1328
                     </td>
1329
                     <td>
1330
                        <p>Overwritten or augmented by Saxon?</p>
1331
                     </td>
1332
                     <td>
1333
                        <p>Can be set from Java API?</p>
1334
                     </td>
1335
                  </tr>
1336
               </thead>
1337
               <tr>
1338
                  <td>
1339
                     <p>XPath 1.0 Compatibility Mode</p>
1340
                  </td>
1341
                  <td>
1342
                     <p>no</p>
1343
                  </td>
1344
                  <td>
1345
                     <p>no</p>
1346
                  </td>
1347
               </tr>
1348
               <tr>
1349
                  <td>
1350
                     <p>Statically known namespaces</p>
1351
                  </td>
1352
                  <td>
1353
                     <p>no</p>
1354
                  </td>
1355
                  <td>
1356
                     <p>yes</p>
1357
                  </td>
1358
               </tr>
1359
               <tr>
1360
                  <td>
1361
                     <p>Default element/type namespace</p>
1362
                  </td>
1363
                  <td>
1364
                     <p>no</p>
1365
                  </td>
1366
                  <td>
1367
                     <p>yes</p>
1368
                  </td>
1369
               </tr>
1370
               <tr>
1371
                  <td>
1372
                     <p>Default function namespace</p>
1373
                  </td>
1374
                  <td>
1375
                     <p>no</p>
1376
                  </td>
1377
                  <td>
1378
                     <p>no</p>
1379
                  </td>
1380
               </tr>
1381
               <tr>
1382
                  <td>
1383
                     <p>In-scope schema types</p>
1384
                  </td>
1385
                  <td>
1386
                     <p>yes: types corresponding to Java classes for use in extension functions</p>
1387
                  </td>
1388
                  <td>
1389
                     <p>no</p>
1390
                  </td>
1391
               </tr>
1392
               <tr>
1393
                  <td>
1394
                     <p>In-scope element declarations</p>
1395
                  </td>
1396
                  <td>
1397
                     <p>no</p>
1398
                  </td>
1399
                  <td>
1400
                     <p>no</p>
1401
                  </td>
1402
               </tr>
1403
               <tr>
1404
                  <td>
1405
                     <p>In-scope attribute declarations</p>
1406
                  </td>
1407
                  <td>
1408
                     <p>no</p>
1409
                  </td>
1410
                  <td>
1411
                     <p>no</p>
1412
                  </td>
1413
               </tr>
1414
               <tr>
1415
                  <td>
1416
                     <p>In-scope variables</p>
1417
                  </td>
1418
                  <td>
1419
                     <p>no</p>
1420
                  </td>
1421
                  <td>
1422
                     <p>no</p>
1423
                  </td>
1424
               </tr>
1425
               <tr>
1426
                  <td>
1427
                     <p>Context item static type</p>
1428
                  </td>
1429
                  <td>
1430
                     <p>no</p>
1431
                  </td>
1432
                  <td>
1433
                     <p>no</p>
1434
                  </td>
1435
               </tr>
1436
               <tr>
1437
                  <td>
1438
                     <p>Function signatures</p>
1439
                  </td>
1440
                  <td>
1441
                     <p>yes: any Java method on the classpath can be referenced</p>
1442
                  </td>
1443
                  <td>
1444
                     <p>yes: there is a plug-in mechanism</p>
1445
                  </td>
1446
               </tr>
1447
               <tr>
1448
                  <td>
1449
                     <p>Statically known collations</p>
1450
                  </td>
1451
                  <td>
1452
                     <p>yes: collations of the form http://saxon.sf.net/collation?<i>params</i>
1453
                     </p>
1454
                  </td>
1455
                  <td>
1456
                     <p>yes</p>
1457
                  </td>
1458
               </tr>
1459
               <tr>
1460
                  <td>
1461
                     <p>Default collation</p>
1462
                  </td>
1463
                  <td>
1464
                     <p>no</p>
1465
                  </td>
1466
                  <td>
1467
                     <p>yes</p>
1468
                  </td>
1469
               </tr>
1470
               <tr>
1471
                  <td>
1472
                     <p>Construction mode</p>
1473
                  </td>
1474
                  <td>
1475
                     <p>no</p>
1476
                  </td>
1477
                  <td>
1478
                     <p>no</p>
1479
                  </td>
1480
               </tr>
1481
               <tr>
1482
                  <td>
1483
                     <p>Ordering mode</p>
1484
                  </td>
1485
                  <td>
1486
                     <p>no</p>
1487
                  </td>
1488
                  <td>
1489
                     <p>no</p>
1490
                  </td>
1491
               </tr>
1492
               <tr>
1493
                  <td>
1494
                     <p>Default order for empty sequences</p>
1495
                  </td>
1496
                  <td>
1497
                     <p>no</p>
1498
                  </td>
1499
                  <td>
1500
                     <p>no</p>
1501
                  </td>
1502
               </tr>
1503
               <tr>
1504
                  <td>
1505
                     <p>Boundary-space policy</p>
1506
                  </td>
1507
                  <td>
1508
                     <p>no</p>
1509
                  </td>
1510
                  <td>
1511
                     <p>no</p>
1512
                  </td>
1513
               </tr>
1514
               <tr>
1515
                  <td>
1516
                     <p>Copy-namespaces mode</p>
1517
                  </td>
1518
                  <td>
1519
                     <p>no</p>
1520
                  </td>
1521
                  <td>
1522
                     <p>no</p>
1523
                  </td>
1524
               </tr>
1525
               <tr>
1526
                  <td>
1527
                     <p>Base URI</p>
1528
                  </td>
1529
                  <td>
1530
                     <p>yes: inferred from the location of the query</p>
1531
                  </td>
1532
                  <td>
1533
                     <p>yes</p>
1534
                  </td>
1535
               </tr>
1536
               <tr>
1537
                  <td>
1538
                     <p>Statically known documents</p>
1539
                  </td>
1540
                  <td>
1541
                     <p>no</p>
1542
                  </td>
1543
                  <td>
1544
                     <p>no</p>
1545
                  </td>
1546
               </tr>
1547
               <tr>
1548
                  <td>
1549
                     <p>Statically known collections</p>
1550
                  </td>
1551
                  <td>
1552
                     <p>no</p>
1553
                  </td>
1554
                  <td>
1555
                     <p>no</p>
1556
                  </td>
1557
               </tr>
1558
               <tr>
1559
                  <td>
1560
                     <p>Statically known default collection type</p>
1561
                  </td>
1562
                  <td>
1563
                     <p>no</p>
1564
                  </td>
1565
                  <td>
1566
                     <p>no</p>
1567
                  </td>
1568
               </tr>
1569
            </table>
1570

1571
            <p>For the dynamic context, the corresponding settings are:</p>
1572
            <table>
1573
               <thead>
1574
                  <tr>
1575
                     <td>
1576
                        <p>Component</p>
1577
                     </td>
1578
                     <td>
1579
                        <p>Overwritten or augmented by Saxon?</p>
1580
                     </td>
1581
                     <td>
1582
                        <p>Can be set from Java API?</p>
1583
                     </td>
1584
                  </tr>
1585
               </thead>
1586
               <tr>
1587
                  <td>
1588
                     <p>Context item</p>
1589
                  </td>
1590
                  <td>
1591
                     <p>no</p>
1592
                  </td>
1593
                  <td>
1594
                     <p>yes</p>
1595
                  </td>
1596
               </tr>
1597
               <tr>
1598
                  <td>
1599
                     <p>Context position</p>
1600
                  </td>
1601
                  <td>
1602
                     <p>no</p>
1603
                  </td>
1604
                  <td>
1605
                     <p>no</p>
1606
                  </td>
1607
               </tr>
1608
               <tr>
1609
                  <td>
1610
                     <p>Context size</p>
1611
                  </td>
1612
                  <td>
1613
                     <p>no</p>
1614
                  </td>
1615
                  <td>
1616
                     <p>no</p>
1617
                  </td>
1618
               </tr>
1619
               <tr>
1620
                  <td>
1621
                     <p>Variable values</p>
1622
                  </td>
1623
                  <td>
1624
                     <p>no</p>
1625
                  </td>
1626
                  <td>
1627
                     <p>only for declared external variables</p>
1628
                  </td>
1629
               </tr>
1630
               <tr>
1631
                  <td>
1632
                     <p>Function implementations</p>
1633
                  </td>
1634
                  <td>
1635
                     <p>no</p>
1636
                  </td>
1637
                  <td>
1638
                     <p>yes (extension functions)</p>
1639
                  </td>
1640
               </tr>
1641
               <tr>
1642
                  <td>
1643
                     <p>Current dateTime</p>
1644
                  </td>
1645
                  <td>
1646
                     <p>yes (from system clock)</p>
1647
                  </td>
1648
                  <td>
1649
                     <p>yes</p>
1650
                  </td>
1651
               </tr>
1652
               <tr>
1653
                  <td>
1654
                     <p>Implicit timezone</p>
1655
                  </td>
1656
                  <td>
1657
                     <p>yes (from system clock)</p>
1658
                  </td>
1659
                  <td>
1660
                     <p>yes</p>
1661
                  </td>
1662
               </tr>
1663
               <tr>
1664
                  <td>
1665
                     <p>Available documents</p>
1666
                  </td>
1667
                  <td>
1668
                     <p>yes (all documents reachable using Java URL connections)</p>
1669
                  </td>
1670
                  <td>
1671
                     <p>yes (URIResolver)</p>
1672
                  </td>
1673
               </tr>
1674
               <tr>
1675
                  <td>
1676
                     <p>Available collections</p>
1677
                  </td>
1678
                  <td>
1679
                     <p>no</p>
1680
                  </td>
1681
                  <td>
1682
                     <p>yes (CollectionResolver/catalog)</p>
1683
                  </td>
1684
               </tr>
1685
               <tr>
1686
                  <td>
1687
                     <p>Default collection</p>
1688
                  </td>
1689
                  <td>
1690
                     <p>no</p>
1691
                  </td>
1692
                  <td>
1693
                     <p>yes (CollectionResolver/catalog)</p>
1694
                  </td>
1695
               </tr>
1696
            </table>
1697
         </li>
1698
         <li>
1699

1700
            <p>
1701
               <i>Which of the optional axes are supported by the implementation, if the Full-Axis
1702
                  Feature is not supported.</i>
1703
            </p>
1704

1705
            <p>&#x25BA; The Full-Axis features is supported.</p>
1706
         </li>
1707
         <li>
1708

1709
            <p>
1710
               <i>The default handling of empty sequences returned by an ordering key (sortspec) in
1711
                  an order by clause (empty least or empty greatest).</i>
1712
            </p>
1713

1714
            <p>&#x25BA; Empty least.</p>
1715
         </li>
1716
         <li>
1717

1718
            <p>
1719
               <i>The names and semantics of any extension expressions (pragmas) recognized by the
1720
                  implementation.</i>
1721
            </p>
1722

1723
            <p>&#x25BA; Saxon-EE recognizes one pragma: <code>saxon:validate-type</code>. For details, see <a
1724
                  class="bodylink" href="/using-xquery/extensions">XQuery Extensions</a>.</p>
1725
         </li>
1726
         <li>
1727

1728
            <p>
1729
               <i>The names and semantics of any option declarations recognized by the
1730
                  implementation.</i>
1731
            </p>
1732

1733
            <p>&#x25BA; See <a class="bodylink" href="/using-xquery/extensibility">XQuery
1734
               Extensibility</a>.</p>
1735
         </li>
1736
         <li>
1737

1738
            <p>
1739
               <i>Protocols (if any) by which parameters can be passed to an external function, and
1740
                  the result of the function can be returned to the invoking query.</i>
1741
            </p>
1742

1743
            <p>&#x25BA; Java methods can be called as <a class="bodylink" href="/extensibility/functions"
1744
                  >Extension Functions</a>.</p>
1745
         </li>
1746
         <li>
1747

1748
            <p>
1749
               <i>How the implementation handles location hints in module imports, if the Module
1750
                  Feature is supported.</i>
1751
            </p>
1752

1753
            <p>&#x25BA; The location hint is interpreted as a relative URI, relative to the base URI of the
1754
               referencing module. It is then dereferenced using the Java URL mechanisms, unless the
1755
               user has nominated a <code>ModuleURIResolver</code>, in which case the interpretation
1756
               is under user control.</p>
1757
         </li>
1758
         <li>
1759

1760
            <p>
1761
               <i>Any static typing extensions supported by the implementation, if the Static Typing
1762
                  Feature is supported.</i>
1763
            </p>
1764

1765
            <p>&#x25BA; Not applicable.</p>
1766
         </li>
1767
         <li>
1768

1769
            <p>
1770
               <i>The means by which serialization is invoked, if the Serialization Feature is
1771
                  supported.</i>
1772
            </p>
1773

1774
            <p>&#x25BA; Serialization may be invoked from the command line or from the Java or .NET API.
1775
               Serialization parameters may be supplied on the command line, from the Java or .NET
1776
               API, or through option declarations in the query prolog.</p>
1777
         </li>
1778
         <li>
1779

1780
            <p>
1781
               <i>The default values for the byte-order-mark, encoding, media-type,
1782
                  normalization-form, omit-xml-declaration, standalone, and version parameters, if
1783
                  the Serialization Feature is supported.</i>
1784
            </p>
1785

1786
            <p>&#x25BA; As specified in Appendix C.3 of the XQuery specification.</p>
1787
         </li>
1788
      </ol>
1789
   </section>-->
1790
   <section id="xquery31" title="XQuery 3.1 Conformance">
1791
      <h1>XQuery 3.1 Conformance</h1>
1792

    
1793

    
1794
      <p>Saxon 10 fully implements the final XQuery 3.1 <a
1795
            class="bodylink" href="http://www.w3.org/TR/xquery-31/">Recommendation</a> of 21 March 2017. (Saxon 9.8 also claimed full conformance,
1796
      and the situation is unchanged except for a small number of bugs that have been reported.)</p>
1797

    
1798
      <p>See also <a class="bodylink" href="../xpath31">XPath 3.1 Conformance</a>; all the new
1799
         features implemented for XPath 3.1 are also available in XQuery 3.1.</p>
1800
      
1801
      <h2 class="subtitle">Test results</h2>
1802
      
1803
      <p>At the time of release Saxon-EE 10.0 passes all 31009 applicable tests in the W3C XPath/XQuery test suite (QT3). 
1804
        Tests are run on both
1805
         the Java and .NET platforms, with bytecode enabled and disabled. Since many of the tests are simple constant expressions (for example,
1806
         <code>contains("banana", "n")</code>), which will normally be pre-evaluated during expression optimization and thus never result in bytecode
1807
         being generated, the test driver also includes an option to "unfold" the test to create artificial complications: for example the constant
1808
         string <code>"banana"</code> is replaced by a call to a function <code>f:scramble("banana")</code> which actually returns its argument unchanged,
1809
         but only after various manipulations designed to defeat the optimizer.
1810
      </p>
1811
      
1812
      <p>The only tests that are not run are:</p>
1813
      
1814
      <ul>
1815
         <li>415 tests that exercise the optional "static typing feature", which Saxon does not implement (and which W3C
1816
            has discontinued).</li>
1817
         <li>2 tests that expose bugs in the ICU library, used for Unicode collation support. The bugs have been reported.</li>
1818
      </ul>
1819
      
1820
      <p>Although the W3C XQuery Working Group has ceased operation, the W3C QT3 test suite continues to be developed by
1821
         volunteers, and Saxonica remains an active contributor. The test suite can be found at 
1822
         <a href="https://github.com/w3c/qt3tests" class="bodylink">https://github.com/w3c/qt3tests</a>.
1823
         Tests are labeled to indicate which specifications (XPath/XQuery) and versions they apply to.
1824
         Conformance issues raised by Saxon users typically result in new test cases being added to the test suite.</p>
1825
      
1826
      <h2 class="subtitle">Conformance overview</h2>
1827

    
1828
      <p>The various Saxon editions implement XQuery 3.1 capabilities as follows:</p>
1829

    
1830
      <ul>
1831
         <li>
1832
            <p>Saxon-HE and Saxon-PE implement XQuery 3.1 at the <i>Minimal Conformance</i> level, plus the <i>Module
1833
               Feature</i>, the <i>Serialization Feature</i>, and (since Saxon 10) the <i>Higher-Order
1834
            Functions</i> Feature.</p>
1835
         </li>
1836
         <li>
1837
            <p>Saxon-EE adds support for the <i>Schema Aware</i> Feature and the <i>Typed Data Feature</i>.</p>
1838
         </li>
1839
      </ul>
1840

    
1841
      <p>These optional features are defined in the conformance section
1842
         of the <a class="bodylink" href="http://www.w3.org/TR/xquery-31/#id-xquery-conformance"
1843
            >XQuery 3.1 specification</a>.</p>
1844

    
1845
      <p>Saxon does not implement the <i>Static Typing</i> Feature.</p>
1846

    
1847

    
1848
      <p>From 9.8 onwards, Saxon always acts as an XQuery 3.1 processor; it is no longer possible to ask it to
1849
      operate as an XQuery 1.0 or XQuery 3.0 processor. However, there are very few incompatibilities, so queries
1850
      that ran successfully under XQuery 1.0 or XQuery 3.0 will almost certainly continue to work.</p>
1851
     
1852
     <aside>Although Saxon 10 is no longer technically an XQuery 1.0 processor, it still passes
1853
     99.7% of the XQuery 1.0 conformance tests. The tests it fails fall into two categories: (a)
1854
     constructs that XQuery 1.0 processors are supposed to reject, but which XQuery 3.1 accepts, and (b)
1855
     edge cases where XQuery 3.1 has cleaned up the specification: for example XQuery 1.0 allowed
1856
     a function called <code>attribute()</code> to be declared, but didn't allow it to be called.</aside>
1857

    
1858

    
1859
      <h2 class="subtitle">Checklist of Implementation-Defined Items</h2>
1860

    
1861

    
1862
      <p>Appendix D of the XQuery 3.1 specification lists a number of features whose behaviour is
1863
         implementation-defined. For Saxon, the behaviour is as follows:</p>
1864

    
1865
      <ol>
1866
         <li>
1867
            <p>
1868
               <i>The version of Unicode that is used to construct expressions.</i>
1869
            </p>
1870
            <p>
1871
               ► For details of Saxon Unicode support, see
1872
               <a class="bodylink" href="../xslt30">XSLT 3.0 Conformance.</a>
1873
            </p>
1874
         </li>
1875
         <li>
1876
            <p>
1877
               <i>The statically-known collations.</i>
1878
            </p>
1879
            <p>
1880
               ► Collation URIs of the form
1881
               <code>
1882
                  http://saxon.sf.net/collation?
1883
                  <i>param=value;param=value...</i>
1884
               </code>
1885
               are always available: these map to the collations offered by the locales available within the Java VM in use. Additional collation URIs may be implemented by users and registered with the Saxon configuration via the Java API.
1886
            </p>
1887
         </li>
1888
         <li>
1889
            <p>
1890
               <i>The implicit timezone.</i>
1891
            </p>
1892
            <p>
1893
               ► The implicit timezone is normally taken from the system clock. This may, however, be overridden via the Java API.
1894
            </p>
1895
         </li>
1896
         <li>
1897
            <p>
1898
               <i>The circumstances in which warnings are raised, and the ways in which warnings are
1899
                  handled.</i>
1900
            </p>
1901
            <p>
1902
               ► Warnings are raised for a variety of conditions. Compile time warnings include:
1903
            </p>
1904
            <ul>
1905
               <li>
1906
                  <p>
1907
                     Use of a path expression that can never select anything (for example
1908
                     <code>@a/@b</code>
1909
                     )
1910
                  </p>
1911
               </li>
1912
               <li>
1913
                  <p>
1914
                     Use of an expression that can only succeed if one or more operands are empty sequences
1915
                  </p>
1916
               </li>
1917
               <li>
1918
                  <p>
1919
                     Use of a string literal in a <code>PITest</code> that is not a valid <code>NCName</code>
1920
                  </p>
1921
               </li>
1922
            </ul>
1923
            <p>
1924
               Warnings may also be raised at run-time, for example if the
1925
               <code>collection()</code>
1926
               function fails to load a document and recovery has been requested.
1927
            </p>
1928
            <p>
1929
              ► Compile-time warnings are sent to the 
1930
               <code>ErrorReporter</code> registered with the
1931
               s9api <code>XQueryCompiler</code>; the default
1932
               <code>ErrorReporter</code> displays them as messages on
1933
               <code>System.err</code>. Run-time warnings are sent to the 
1934
               <code>ErrorReporter</code> registered with the
1935
               <code>XQueryEvaluator</code>; the default is the same.
1936
            </p>
1937
         </li>
1938
         <li>
1939
            <p>
1940
               <i>The method by which errors are reported to the external processing
1941
                  environment.</i>
1942
            </p>
1943
            <p>
1944
1945
                Compile-time errors are sent to the 
1946
                <code>ErrorReporter</code> registered with the
1947
                s9api <code>XQueryCompiler</code>; the default
1948
                <code>ErrorReporter</code> displays them as messages on
1949
                <code>System.err</code>. Run-time warnings are sent to the 
1950
                <code>ErrorReporter</code> registered with the
1951
                <code>XQueryEvaluator</code>; the default is the same.
1952
              When queries are invoked from a Java application, any error will also 
1953
              be notified by throwing an exception.
1954
            </p>
1955
         </li>
1956
         <li>
1957
            <p>
1958
               <i>Which version of XML and XML Names (e.g. [XML 1.0] and [XML Names] or [XML 1.1]
1959
                  and [XML Names 1.1]) and which version of XML Schema (e.g. [XML Schema 1.0] or
1960
                  [XML Schema 1.1]) is used for the definitions of primitives such as characters and
1961
                  names, and for the definitions of operations such as normalization of line endings
1962
                  and normalization of whitespace in attribute values. It is recommended that the
1963
                  latest applicable version be used (even if it is published later than this
1964
                  specification).</i>
1965
            </p>
1966
            <p>
1967
               ► Saxon gives the user the choice: see
1968
               <a class="bodylink" href="/sourcedocs/xml11">Saxon and XML 1.1</a>. Note that since Saxon allows the user to select which XML parser to use on a per-document basis, achievement of consistency across "all aspects of the implementation" is in part a user responsibility. Saxon will not reject any attempt to use an XML 1.1 parser in a 1.0 configuration, or vice versa.
1969
            </p>
1970
         </li>
1971
         <li>
1972
            <p>
1973
               <i>How XDM instances are created from sources other than an Infoset or PSVI.</i>
1974
            </p>
1975
            <p>► XDM instances may be constructed programmatically, or by wrapping trees constructed 
1976
              using DOM, DOM4J, JDOM, XOM, or AXIOM.</p>
1977
             <p>Most commonly, XDM instances are generated by coupling a SAX parser to a Saxon
1978
             <code>DocumentBuilder</code>.</p>
1979
         </li>
1980
         <li>
1981
            <p>
1982
               <i>Any components of the static context or dynamic context that are overwritten or
1983
                  augmented by the implementation. </i>
1984
            </p>
1985
            <p>► See the corresponding details for XQuery 1.0.</p>
1986
         </li>
1987
         <li>
1988
            <p>
1989
               <i>The default handling of empty sequences returned by an ordering key (orderspec) in
1990
                  an order by clause (empty least or empty greatest). </i>
1991
            </p>
1992
            <p>► Empty least.</p>
1993
         </li>
1994
         <li>
1995
            <p>
1996
               <i>The names and semantics of any extension expressions (pragmas) recognized by the
1997
                  implementation.</i>
1998
            </p>
1999
            <p>
2000
               ► Saxon-EE recognizes one pragma:
2001
               <code>saxon:validate-type</code>. For details, see
2002
               <a class="bodylink" href="/using-xquery/extensions">XQuery Extensions</a>.
2003
            </p>
2004
         </li>
2005
         <li>
2006
            <p>
2007
               <i>The names and semantics of any option declarations recognized by the
2008
                  implementation.</i>
2009
            </p>
2010
            <p>
2011
               ► See
2012
               <a class="bodylink" href="/using-xquery/extensibility">XQuery Extensibility</a>.
2013
            </p>
2014
         </li>
2015
         <li>
2016
            <p>
2017
               <i>Protocols (if any) by which parameters can be passed to an external function, and
2018
                  the result of the function can returned to the invoking query. </i>
2019
            </p>
2020
            <p>
2021
               ► Java methods can be called as
2022
               <a class="bodylink" href="/extensibility/functions">Extension Functions</a>.
2023
            </p>
2024
         </li>
2025
         <li>
2026
            <p>
2027
               <i>The process by which the specific modules to be imported by a module import are
2028
                  identified, if the Module Feature is supported (includes processing of location
2029
                  hints, if any.) </i>
2030
            </p>
2031
            <p>
2032
               ► The location hint is interpreted as a relative URI, relative to the base URI of the referencing module. It is then dereferenced using the Java URL mechanisms, unless the user has nominated a
2033
               <code>ModuleURIResolver</code>, in which case the interpretation is under user control.
2034
            </p>
2035
         </li>
2036
         <li>
2037
            <p>
2038
               <i>The means by which serialization is invoked, if the Serialization Feature is
2039
                  supported.</i>
2040
            </p>
2041
            <p>
2042
               ► Serialization may be invoked from the command line or from the Java or .NET API. Serialization parameters may be supplied on the command line, from the Java or .NET API, or through option declarations in the query prolog.
2043
            </p>
2044
         </li>
2045
         <li>
2046
            <p>
2047
               <i>The default values for the byte-order-mark, encoding, html-version,
2048
                  item-separator, media-type, normalization-form, omit-xml-declaration, standalone,
2049
                  and version parameters, if the Serialization Feature is supported. </i>
2050
            </p>
2051
            <p>
2052
               ► As specified in Appendix C.3 of the XQuery specification.
2053
            </p>
2054
         </li>
2055
         <li>
2056
            <p>
2057
               <i>The result of an unsuccessful call to an external function (for example, if the
2058
                  function implementation cannot be found or does not return a value of the declared
2059
                  type). </i>
2060
            </p>
2061
            <p>
2062
               ► A static or dynamic error.
2063
            </p>
2064
         </li>
2065
         <li>
2066
            <p>
2067
               <i>Limits on ranges of values for various data types, as enumerated in 5.3 Data Model
2068
                  Conformance.</i>
2069
            </p>
2070
            <p>
2071
               ► For integers, decimals, and strings, the only limits imposed by Saxon are those inherent
2072
                  in the underlying Java types <code>BigInteger</code>, <code>BigDecimal</code>, and <code>String</code>. </p>
2073
            <p>► For calendar data types, the year 
2074
                  must be in the range of a signed 32-bit integer; seconds are supported to a
2075
                  fractional precision of nine digits (that is, nanosecond precision). </p>
2076
            <p>► For durations, the number of months must fit in a 
2077
                  signed 32-bit integer; the integer number of seconds must fit in a signed 64-bit integer, and the 
2078
                  precision is to nanoseconds.</p>
2079
            <p>► The maximum length of a sequence (or array) is limited to 2<sup>31</sup>-1 items.</p>
2080
         </li>
2081
         <li>
2082
            <p>
2083
               <i>Syntactic extensions to XQuery, including both their syntax and semantics, as
2084
                  discussed in 5.4 Syntax Extensions. </i>
2085
            </p>
2086
            <p>
2087
               ► None.
2088
            </p>
2089
         </li>
2090
         <li>
2091
            <p>
2092
               <i>Whether the type system is based on [XML Schema 1.0] or [XML Schema 1.1]. An
2093
                  implementation that has based its type system on XML Schema 1.0 is not required to
2094
                  support the use of the <code>xs:dateTimeStamp</code> constructor or the use of <code>xs:dateTimeStamp</code>
2095
                  or <code>xs:error</code> as <code>TypeName</code> in any expression. </i>
2096
            </p>
2097
            <p>
2098
               ► XSD 1.0 or XSD 1.1 at user option.
2099
            </p>
2100
         </li>
2101
         <li>
2102
            <p>
2103
               <i>The signatures of functions provided by the implementation or via an
2104
                  implementation-defined API (see 2.1.1 Static Context).</i>
2105
            </p>
2106
            <p>
2107
               ► A list of all recognized functions is at <a class="bodylink" href="/functions">Function library</a>.
2108
            </p>
2109
         </li>
2110
         <li>
2111
            <p>
2112
               <i>Any environment variables provided by the implementation.</i>
2113
            </p>
2114
            <p>
2115
               ► The environment variables available are those exposed by the Java method <code>System.getenv()</code>.
2116
            </p>
2117
         </li>
2118
         <li>
2119
            <p>
2120
               <i>Any rules used for static typing (see 2.2.3.1 Static Analysis Phase).</i>
2121
            </p>
2122
            <p>
2123
               ► Saxon performs "optimistic static typing": that is, it attempts to infer a type for every expression,
2124
               and reports a type error statically if there is an empty intersection between the inferred type and the required type.
2125
            </p>
2126
         </li>
2127
         <li>
2128
            <p>
2129
               <i>Any serialization parameters provided by the implementation (see 2.2.4
2130
                  Serialization).</i>
2131
            </p>
2132
         </li>
2133
         <li>
2134
            <p>
2135
               <i>The means by which the location hint for a serialization parameter document
2136
                  identifies the corresponding XDM instance (see 2.2.4 Serialization). </i>
2137
            </p>
2138
         </li>
2139
         <li>
2140
            <p>
2141
               <i>What error, if any, is returned if an external function's implementation does not
2142
                  return the declared result type (see 2.2.5 Consistency Constraints). </i>
2143
            </p>
2144
            <p>
2145
               ► Generally, a type error <code>XPTY0004</code>. However, external functions have the option
2146
               to request suppression of this type check, in which case the consequences of the error become unpredictable.
2147
            </p>
2148
         </li>
2149
         <li>
2150
            <p>
2151
               <i>Any annotations defined by the implementation, and their associated behaviour (see
2152
                  4.15 Annotations). </i>
2153
            </p>
2154
            <p>
2155
               ► None.
2156
            </p>
2157
         </li>
2158
         <li>
2159
            <p>
2160
               <i>Any function assertions defined by the implementation.</i>
2161
            </p>
2162
            <p>
2163
               ► None.
2164
            </p>
2165
         </li>
2166
         <li>
2167
            <p>
2168
               <i>The effect of function assertions understood by the implementation on 2.5.6.3 The
2169
                  judgement subtype-assertions(AnnotationsA, AnnotationsB). </i>
2170
            </p>
2171
            <p>
2172
               ► None.
2173
            </p>
2174
         </li>
2175
         <li>
2176
            <p>
2177
               <i>Any implementation-defined variables defined by the implementation (see 3.1.2
2178
                  Variable References). </i>
2179
            </p>
2180
            <p>
2181
               ► None.
2182
            </p>
2183
         </li>
2184
         <li>
2185
            <p>
2186
               <i>The ordering associated with fn:unordered in the implementation (see 3.13 Ordered
2187
                  and Unordered Expressions). </i>
2188
            </p>
2189
            <p>
2190
               ► The <code>fn:unordered</code> function returns its input argument value unchanged in nearly all cases.
2191
               The only exceptions are where the argument is an axis expression that would normally require sorting of results
2192
               into document order (for example, the preceding-sibling axis), in which case the sort is avoided.
2193
            </p>
2194
         </li>
2195
         <li>
2196
            <p>
2197
               <i>Any additional information provided for try/catch via the <code>err:additional</code> variable
2198
                  (see 3.17 Try/Catch Expressions). </i>
2199
            </p>
2200
            <p>
2201
               ► None.
2202
            </p>
2203
         </li>
2204
         <li>
2205
            <p>
2206
               <i>The default boundary-space policy (see 4.3 Boundary-space Declaration).</i>
2207
            </p>
2208
            <p>
2209
               ► Boundary space is significant.
2210
            </p>
2211
         </li>
2212
         <li>
2213
            <p>
2214
               <i>The default collation (see 4.4 Default Collation Declaration).</i>
2215
            </p>
2216
            <p>
2217
               ► The name of the default collation can be specified as a configuration option.
2218
            </p>
2219
         </li>
2220
         <li>
2221
            <p>
2222
               <i>The default base URI (see 4.5 Base URI Declaration).</i>
2223
            </p>
2224
            <p>
2225
               ► The default base URI for a query is taken from the file or URI giving the query location if available, or from an explicit
2226
               setting of the base URI in the XQuery API otherwise.
2227
            </p>
2228
         </li>
2229
      </ol>
2230

    
2231
   </section>
2232

    
2233
   <!--<section id="xquery31" title="XQuery 3.1 Conformance">
2234
      <h1>XQuery 3.1 Conformance</h1>
2235
      <p>Saxon 9.7 fully implements the XQuery 3.1 specification as defined at the time of release.</p>
2236
      
2237
      <aside>A Candidate Recommendation for XQuery 3.1 was published on 18 December 2014. At the release date
2238
      of Saxon 9.7, a revised version of this Candidate Recommendation is believed to be imminent, and Saxon 9.7
2239
      implements its expected content.</aside>
2240

2241
      <p>All the important new features of XQuery 3.1 are also present in XPath 3.1: see <a
2242
            href="../xpath31" class="bodylink">XPath 3.1 Conformance</a>.</p>
2243

2244
      <h2 class="subtitle">Test Results</h2>
2245

2246
      <p>Saxon 9.7, at the time of release, passes all tests in the W3C test suite for XQuery 3.1, other than tests
2247
         for features which Saxon does not implement (for example, static typing), tests whose results have been
2248
         challenged by means of a bug report submitted to W3C, and tests that exceed Saxon limits (for example, a date
2249
         whose year component is 25 digits long).</p>
2250

2251
      <h2 class="subtitle">Checklist of Implementation-Defined Items</h2>
2252

2253
      <p>Appendix D of the XQuery 3.1 specification lists a number of features whose behaviour is
2254
         implementation-defined. The list of features is the same as those in the XQuery 3.0
2255
         specification, so see <a href="../xquery30" class="bodylink">XQuery 3.0 Conformance</a> for
2256
         details of the Saxon behaviour.</p>
2257

2258
   </section>-->
2259
   <section id="schema" title="XML Schema 1.0 Conformance">
2260
      <h1>XML Schema 1.0 Conformance</h1>
2261

    
2262

    
2263
      <p>Saxon Enterprise Edition (Saxon-EE) includes a complete implementation of XML Schema
2264
         1.0.</p>
2265

    
2266
      <p>Test results have been submitted against the W3C XML Schema Test Suite. All deviations from
2267
         the expected test results have been accounted for, and are believed to represent areas
2268
         where the tests are either incorrect, or where implementations can legitimately differ.</p>
2269

    
2270
      <p>Known limitations include the following:</p>
2271
      <ul>
2272
         <li>
2273
            <p>Saxon imposes limits on the values of <code>minOccurs</code> and
2274
                  <code>maxOccurs</code> appearing on any particle other than an element particle in
2275
               a content model. These limits are designed to prevent out-of-memory errors. By
2276
               default, the upper limit for <code>minOccurs</code> is 100 and the upper limit for
2277
                  <code>maxOccurs</code> (other than "unbounded") is 250. If these limits are
2278
               exceeded, a warning is output, and the values specified are replaced with the highest
2279
               allowed value (which is "unbounded" in the case of <code>maxOccurs</code>). The
2280
               limits are configurable using the method <code>setOccurrenceLimits()</code> in the
2281
               class <a class="javalink" href="com.saxonica.config.EnterpriseConfiguration"
2282
                  >EnterpriseConfiguration</a>. If they are set too high, however, out-of-memory or
2283
               stack overflow errors will occur either during schema compilation or during instance
2284
               validation. Since Saxon 9.1, these limits no longer apply to the common case of
2285
               element particles, which are now handled using counters.</p>
2286
         </li>
2287
         <li>
2288
            <p>Saxon implements schema processing only to the extent required for XPath, XSLT, and
2289
               XQuery processing and for assessment of document validity. This means that PSVI
2290
               properties beyond those required for the XPath data model are not provided. It also
2291
               means that validation errors are fatal, they do not result in a PSVI that indicates
2292
               the validation outcome for individual nodes.</p>
2293
         </li>
2294

    
2295
         <li>
2296
            <p>Saxon uses the rules in XSD 1.1 rather than those in XSD 1.0 to evaluate type
2297
               subsumption. The Saxon algorithm (an implementation of the algorithm published by
2298
               Henry Thompson and Richard Tobin of the University of Edinburgh) is more accurate
2299
               than the one in the XSD 1.0 specification in deciding whether one complex type
2300
               subsumes another. It therefore permits some complex type restrictions that the cruder
2301
               XSD 1.0 algorithm disallows.</p>
2302
         </li>
2303
         <li>
2304
            <p>Saxon also uses the Thomson and Tobin algorithm to evaluate the Unique Particle
2305
               Attribution constraint. The effect of this is that no UPA violation is reported when
2306
               a complex type contains two distinct element particles that are references to the
2307
               same element declaration, since the element declaration can be identified
2308
               unambiguously.</p>
2309
         </li>
2310
         <li>
2311
            <p>Saxon does not allow a user-defined type to be derived directly from
2312
                  <code>xs:anySimpleType</code>. It seems that the XSD 1.0 specification does not
2313
               disallow this, though the effect of doing it is very unclear, and it has been banned
2314
               in XSD 1.1.</p>
2315
         </li>
2316

    
2317
      </ul>
2318
   </section>
2319
   <section id="schema11" title="XML Schema 1.1 Conformance">
2320
      <h1>XML Schema 1.1 Conformance</h1>
2321

    
2322

    
2323
      <p>Saxon Enterprise Edition (Saxon-EE) includes a complete implementation of the XSD 1.1
2324
         Recommendation of 5 April 2012. There is a test suite that is believed to cover all new
2325
         features of the specification, and Saxon achieves 100% pass rate againts these tests.</p>
2326

    
2327
      <p>From Saxon 9.8, XSD 1.1 processing is the default; if XSD 1.0 is required, it must be explicitly requested by using the
2328
            <code>-xsdversion:1.0</code> option on the command line, or equivalent options in the
2329
         API.</p>
2330

    
2331
      <p>The rules for valid type derivation follow the XML Schema 1.1 specification, regardless of
2332
         this option setting. This is because the rules in the 1.0 specification do not meet the
2333
         stated intent, namely that type derivation is valid in all cases where the restricted type
2334
         allows a subset of the instances permitted by the base type.</p>
2335

    
2336
      <p>An outline of the changes between XSD 1.0 and XSD 1.1 can be found in <a
2337
            href="http://www.w3.org/TR/xmlschema11-1/#changes" class="bodylink">Appendix G of the
2338
            specification</a>.</p>
2339

    
2340

    
2341
      <h2 class="subtitle">Implementation-defined features</h2>
2342

    
2343
      <p>Appendix E.1 of XSD 1.1 (Part 1: Structures) provides a checklist of implementation-defined
2344
         and implementation-dependent features. The following list describes how these are
2345
         implemented in Saxon.</p>
2346

    
2347
      <ul>
2348
         <li>
2349
            <p>
2350
               <i>For the datatypes defined by [XML Schema: Datatypes] which depend on [XML 1.1] or
2351
                  [XML Namespaces 1.1], it is ·implementation-defined· whether a schema processor
2352
                  takes the relevant definitions from [XML 1.1] and [XML Namespaces 1.1], or from
2353
                  [XML 1.0] and [Namespaces in XML 1.0]. Implementations may support either the
2354
                  ·XML-1.0-based· datatypes, or the ·XML-1.1-based· datatypes, or both. The same
2355
                  applies to the definition of whitespace. </i>
2356
            </p>
2357
            <p>&#x25BA; The definition of whitespace is the same in all XML editions. The definition of the
2358
               syntax of names is the same in XML 1.1 and in XML 1.0 fifth edition, and Saxon uses
2359
               this definition.</p>
2360
         </li>
2361
         <li>
2362
            <p>
2363
               <i>It is ·implementation-defined· whether a schema processor can read schema
2364
                  documents in the form of XML documents. </i>
2365
            </p>
2366
            <p>Saxon-EE can read XML schema documents.</p>
2367
         </li>
2368
         <li>
2369
            <p>
2370
               <i>Whether a processor is able to retrieve schema documents from the Web is
2371
                  ·implementation-defined·. (See Conformance (§2.4), which defines "·Web-aware·"
2372
                  processors as processors which can retrieve schema documents from the Web.) </i>
2373
            </p>
2374
            <p>&#x25BA; Saxon-EE is able to read XML schema documents from the Web.</p>
2375
         </li>
2376
         <li>
2377
            <p>
2378
               <i>The way in which a processor is invoked, and the way in which values are specified
2379
                  for the schema to be used, the information item to be validated, and the
2380
                  declaration or definition with which to begin validation, is
2381
                  ·implementation-defined·. </i>
2382
            </p>
2383
            <p>&#x25BA; Saxon-EE allows validation to be invoked from the command line, via a Java or .NET
2384
               API, or from XSLT and XQuery. The documentation for interfaces provides the required
2385
               information.</p>
2386
         </li>
2387
         <li>
2388
            <p>
2389
               <i>The manner in which a processor provides access to the information items and
2390
                  properties in the PSVI to any downstream or user applications, or to the invoker,
2391
                  is ·implementation-defined·. </i>
2392
            </p>
2393
            <p>&#x25BA; Saxon provides only that part of the PSVI used by the XQuery and XSLT specifications.
2394
               This amounts to adding a type annotation to each element and attribute node where the
2395
               outcome of validation is 'valid', and providing error messages where it is not.</p>
2396
         </li>
2397
         <li>
2398
            <p>
2399
               <i>The information items and properties in the PSVI to which the processor provides
2400
                  access, if any, is ·implementation-defined·. </i>
2401
            </p>
2402
            <p>&#x25BA; See previous answer.</p>
2403
         </li>
2404
         <li>
2405
            <p>
2406
               <i>When the ·post-schema-validation infoset· includes [type definition name] and
2407
                  similar properties, it is ·implementation-defined· whether unique names are
2408
                  provided for anonymous type definitions. </i>
2409
            </p>
2410
            <p>&#x25BA; Saxon allocates unique names to anonymous type definitions.</p>
2411
         </li>
2412
         <li>
2413
            <p>
2414
               <i>The method used for assembling a set of schema components for use in validation is
2415
                  ·implementation-defined·. </i>
2416
            </p>
2417
            <p>&#x25BA; Saxon generally assembles schema components from XML schema documents as described in
2418
               the XSD specification. However, it has built-in knowledge of the schema for the XML
2419
               namespace, and these components can be included in a schema simply by importing the
2420
               relevant namespace. It also has built-in knowledge of the schema components defined
2421
               in the FN namespace, used in the result document of the <code>analyze-string</code>
2422
               function in XPath 3.0.</p>
2423
         </li>
2424
         <li>
2425
            <p>
2426
               <i>It is ·implementation-defined· whether a schema processor provides a value for the
2427
                  [type definition name] and [member type definition name] properties of attribute
2428
                  and element information-items. If it does so, the choice of name is
2429
                  ·implementation-dependent·. </i>
2430
            </p>
2431
            <p>&#x25BA; The information is not directly available.</p>
2432
         </li>
2433
         <li>
2434
            <p>
2435
               <i>Everything ·implementation-defined· in [XML Schema: Datatypes] is also
2436
                  ·implementation-defined· in this specification. Note: This includes, but is not
2437
                  limited to, the choice of ·XML-1.0-based· or ·XML-1.1-based· datatypes, or both;
2438
                  support for ·implementation-defined· primitive datatypes; and support for
2439
                  ·implementation-defined· constraining facets. See the appendix on
2440
                  implementation-defined and implementation-dependent features in [XML Schema:
2441
                  Datatypes]. </i>
2442
            </p>
2443
            <p>&#x25BA; See the checklist that follows.</p>
2444
         </li>
2445
         <li>
2446
            <p>
2447
               <i>It is ·implementation-defined· whether a processor detects violations of clause
2448
                  2.4.2 of Derivation Valid (Restriction, Complex) (§3.4.6.3) (a) always by
2449
                  examination of the schema in isolation, (b) only when some element information
2450
                  item in the input document is valid against its ·governing type definition· T but
2451
                  not against T.{base type definition}, or (c) sometimes the one and sometimes the
2452
                  other. In case (c), the circumstances in which the processor does one or the other
2453
                  are ·implementation-dependent·. </i>
2454
            </p>
2455
            <p>&#x25BA; Saxon-EE attempts to detect all violations of Derivation Valid by examination of the
2456
               schema in isolation; if it is not able to determine at this stage that the derivation
2457
               is valid, the schema is considered to be in error.</p>
2458
         </li>
2459
         <li>
2460
            <p>
2461
               <i>It is ·implementation-defined· when a processor detects type errors in XPath
2462
                  expressions and whether it treats type errors as static or dynamic errors. </i>
2463
            </p>
2464
            <p>&#x25BA; Saxon uses optimistic static type checking; it reports a static error in the XPath
2465
               expression if its type analysis concludes that the type of a supplied value and the
2466
               type required by the context in which it is used are disjoint, so that execution can
2467
               never succeed.</p>
2468
         </li>
2469
         <li>
2470
            <p>
2471
               <i>It is ·implementation-defined· under what conditions a processor will detect the
2472
                  equivalence of two distinct Type Table or Type Alternative components. All
2473
                  processors must detect equivalence under certain specified conditions, but the
2474
                  ability to detect equivalence under other conditions is not constrained. </i>
2475
            </p>
2476
            <p>&#x25BA; In considering whether two type tables are equivalent, Saxon tests the equivalence of
2477
               XPath expressions by comparing their normalized expression trees. Inessential factors
2478
               such as whitespace and parentheses are therefore ignored, and in some cases different
2479
               expressions are recognized as equivalent, for example <code>(a=b)</code> is
2480
               equivalent to <code>(b=a)</code>. In general the two expressions must have the same
2481
               static context, but differences in the static context that do not affect the outcome
2482
               of evaluating the expressions may be discounted.</p>
2483

    
2484
         </li>
2485
         <li>
2486
            <p>
2487
               <i>It is ·implementation-defined· what effect invalid elements within
2488
                  &lt;annotation&gt; have on the construction of schema components from a schema
2489
                  document, and whether a processor treats schema documents which are invalid only
2490
                  in consequence of containing such invalid elements as being in ·error· or not.
2491
               </i>
2492
            </p>
2493
            <p>&#x25BA; Saxon ignores the content of annotations entirely, other than ensuring that they are
2494
               namespace-well-formed.</p>
2495
         </li>
2496
      </ul>
2497

    
2498
      <p>A similar checklist appears in appendix H.1 of XSD 1.1 (Part 2: Datatypes). The
2499
         corresponding answers for Saxon-EE are given below.</p>
2500

    
2501
      <ul>
2502
         <li>
2503
            <p>
2504
               <i>For the datatypes which depend on [XML] or [Namespaces in XML], it is
2505
                  ·implementation-defined· whether a conforming processor takes the relevant
2506
                  definitions from [XML] and [Namespaces in XML], or from [XML 1.0] and [Namespaces
2507
                  in XML 1.0]. Implementations may support either the form of these datatypes based
2508
                  on version 1.0 of those specifications, or the form based on version 1.1, or both.
2509
               </i>
2510
            </p>
2511
            <p>&#x25BA; See above. The definitions are taken from XML 1.0 Fifth Edition and XML 1.1, which
2512
               are identical.</p>
2513
         </li>
2514
         <li>
2515
            <p>
2516
               <i>For the datatypes with infinite ·value spaces·, it is ·implementation-defined·
2517
                  whether conforming processors set a limit on the size of the values supported. If
2518
                  such limits are set, they must be documented, and the limits must be equal to, or
2519
                  exceed, the minimal limits specified in Partial Implementation of Infinite
2520
                  Datatypes (§5.4). . </i>
2521
            </p>
2522
            <p>&#x25BA; For integers, decimals, and strings, the only limits imposed by Saxon are those
2523
               inherent in the underlying Java types <code>BigInteger</code>,
2524
                  <code>BigDecimal</code>, and <code>String</code>.</p>
2525
            <p>&#x25BA; For calendar data types, the year must be in the range of a signed 32-bit
2526
               integer.</p>
2527
            <p>&#x25BA; For durations, the number of months must fit in a signed 32-bit integer; the integer
2528
               number of seconds must fit in a signed 64-bit integer, and the precision is to
2529
               microseconds.</p>
2530
         </li>
2531
         <li>
2532
            <p>
2533
               <i>It is ·implementation-defined· whether ·primitive· datatypes other than those
2534
                  defined in this specification are supported. </i>
2535
            </p>
2536
            <p>&#x25BA; Saxon does not support any additional primitive datatypes.</p>
2537
         </li>
2538

    
2539
         <li>
2540
            <p>
2541
               <i>It is ·implementation-defined· whether ·constraining facets· other than those
2542
                  defined in this specification are supported. </i>
2543
            </p>
2544
            <p>&#x25BA; Saxon supports an additional facet, <code>saxon:preprocess</code>. This is a
2545
               pre-lexical facet that invokes user-written Java code to modify a value before
2546
               validation and before serialization. For example, this can be used to allow
2547
                  <code>xs:decimal</code> values to be written using comma as a decimal point. For
2548
               details see <a class="bodylink" href="/schema-processing/extensions11/preprocess">The
2549
                  saxon:preprocess facet</a>.</p>
2550
         </li>
2551
      </ul>
2552

    
2553
   </section>
2554
   <section id="serialization" title="Serialization">
2555
      <h1>Serialization</h1>
2556
      
2557
      <p>Saxon implements the <a href="https://www.w3.org/TR/xslt-xquery-serialization-31/" class="bodylink">XSLT and XQuery Serialization 3.1 Recommendation</a>
2558
      dated 21 March 2017.</p>
2559

    
2560
      <p>Saxon implements all the mandatory provisions of Serialization 3.1.</p>
2561

    
2562
      <p>The known non-conformances are:</p>
2563
      <ul>
2564
         <li>
2565
            <p>Serialization 3.1 states that characters that can be natively encoded in the chosen
2566
               encoding must be natively encoded and must not be represented using character or
2567
               entity references. Saxon behaves this way by default, but provides an extension,
2568
                  <code>saxon:character-representation</code>, which changes the behaviour. Such
2569
               extensions have been declared non-conformant, but this one is retained in
2570
               Saxon for backwards compatibility reasons.</p>
2571
         </li>
2572
      </ul>
2573
      <h2 class="subtitle">Implementation-defined aspects of Serialization</h2>
2574

    
2575
      <p>This section defines how Saxon interprets those aspects of Serialization 3.1 that are
2576
         implementation-defined. The list follows the numbering of <a
2577
            href="https://www.w3.org/TR/xslt-xquery-serialization-31/#implementation-defined-or-dependent-features"
2578
            class="bodylink">Appendix E</a> of the Serialization specification.</p>
2579
      <ol>
2580
         <li>
2581

    
2582
            <p>
2583
               <i>For any implementation-defined output method, it is implementation-defined whether
2584
                  sequence normalization process takes place. (See 2 Sequence Normalization) </i>
2585
            </p>
2586

    
2587
            <p>&#x25BA; Sequence normalization takes place for all output methods other than <code>json</code> and <code>adaptive</code>, 
2588
               including user-defined output methods.</p>
2589
         </li>
2590
         <li>
2591

    
2592
            <p>
2593
               <i>If the namespace URI is non-null for the method serialization parameter, then the
2594
                  parameter specifies an implementation-defined output method. (See 3 Serialization
2595
                  Parameters) </i>
2596
            </p>
2597

    
2598
            <p>&#x25BA; In such cases the local name of the method must be the name of a Java class that
2599
               implements one of the interfaces <code>org.xml.sax.ContentHandler</code>,
2600
                  <code>net.sf.saxon.event.Emitter</code>, or
2601
                  <code>net.sf.saxon.event.Receiver</code>. The class is loaded from the classpath
2602
               and then takes responsibility for producing the serialized output (if any). The
2603
               actual namespace URI is ignored.</p>
2604
         </li>
2605
         <li>
2606
            <p><i>The effect of additional serialization parameters on the output of the serializer, 
2607
               where the name of such a parameter MUST be namespace-qualified, is implementation-defined 
2608
               or implementation-dependent. The extent of this effect on the output MUST NOT override 
2609
               the provisions of this specification. (See 3 Serialization Parameters)
2610
            </i></p>
2611
            <p>&#x25BA; Saxon (PE and EE) defines a number of serialization parameters in the Saxon namespace,
2612
               documented at <a href="/extensions/output-extras/serialization-parameters"
2613
                  class="bodylink">Extensions: Serialization Parameters</a>. Other parameters 
2614
               in the Saxon namespace are rejected; parameters in other namespaces are generally ignored.</p>
2615
         </li>
2616
         <li>
2617
            <p><i>Implementation-defined schema components MAY be included in the set of schema components 
2618
               that are used in evaluating an XQuery expression or XSLT instruction in the process of using 
2619
               an XDM instance to determine the serialization parameters. (See 3.1 Setting Serialization 
2620
               Parameters by Means of a Data Model Instance)</i></p>
2621
            <p>&#x25BA; Saxon does not include any such schema components.</p>
2622
         </li>
2623
         <li>
2624
            <p><i>If an instance of the data model used to determine the settings of serialization 
2625
               parameters contains elements or attributes that are in a namespace other than 
2626
               <code>http://www.w3.org/2010/xslt-xquery-serialization</code>, the implementation MAY interpret 
2627
               them to specify the values of implementation-defined serialization parameters in an 
2628
               implementation-defined manner. (See 3.1 Setting Serialization Parameters by Means of 
2629
               a Data Model Instance)</i></p>
2630
            <p>&#x25BA; Saxon (PE and EE) recognizes additional serialization parameters in the Saxon namespace:
2631
               see <a href="/extensions/output-extras/serialization-parameters"
2632
                  class="bodylink">Extensions: Serialization Parameters</a>.</p>
2633
         </li>
2634
         <li>
2635
            <p><i>The effect of providing an option that allows the encoding phase to be skipped, 
2636
               so that the result of serialization is a stream of Unicode characters, is implementation-defined. 
2637
               The serializer is not required to support such an option. (See 4 Phases of Serialization)</i></p>
2638
            <p>&#x25BA; Saxon allows the serialized output to be written to a Java <code>Writer</code>, which
2639
               is a character stream. In this case no encoding takes place.</p>
2640
         </li>
2641
         <li>
2642
            <p><i>If an implementation supports a value of the <code>version</code> parameter for the XML or XHTML 
2643
               output method for which this document does not provide a normative definition, 
2644
               the behavior is implementation-defined. (See 5.1.1 XML Output Method: the version Parameter)
2645
            </i></p>
2646
            <p>&#x25BA; Saxon recognizes <code>version="1.0"</code> and <code>"1.1"</code> only; other
2647
               versions result in an error.</p>
2648
         </li>
2649
         <li>
2650
            <p><i>A serializer MAY provide an implementation-defined mechanism to place CDATA sections 
2651
               in the result tree. (See 5.1.5 XML Output Method: the cdata-section-elements Parameter)</i></p>
2652
               
2653
               <p>&#x25BA; Saxon defines a factory class that enables Java applications to insert user-defined
2654
                  classes into the serialization pipeline. This mechanism could be used to override the
2655
                  standard CDATA processing.</p>
2656
         </li>
2657
         
2658
         <li>
2659

    
2660
            <p>
2661
               <i>If the value of the <code>normalization-form</code> parameter is not <code>NFC</code>,
2662
                  <code>NFD</code>, <code>NFKC</code>, <code>NFKD</code>, <code>fully-normalized</code>, or
2663
                  <code>none</code> then the meaning of the value and its effect is
2664
                  implementation-defined. (See 4 Phases of Serialization) </i>
2665
            </p>
2666

    
2667
            <p>&#x25BA; Any value other than those listed is an error.</p>
2668
         </li>
2669
         <li>
2670
            <p><i>For the HTML output method, it is implementation-defined whether the <code>basefont</code>, 
2671
               <code>frame</code> and <code>isindex</code> elements, which are not part of HTML5, are considered to be void 
2672
               elements when the requested HTML version has the value 5.0. (See 7.1 Markup for Elements)</i></p>
2673
            <p>&#x25BA; Saxon recognizes these three elements as void.</p>
2674
         </li>
2675
         <li>
2676
            <p><i>If an implementation supports a value of the <code>version</code> parameter for the HTML 
2677
               output method for which this document does not provide a normative definition, the behavior 
2678
               is implementation-defined. (See 7.4.1 HTML Output Method: the version and html-version Parameters)</i></p>
2679
            <p>&#x25BA; Saxon requires the version to be a decimal number. If the value is 5.0 or greater, HTML5
2680
            serialization is used. If it is less than 5.0, HTML 4.0 serialization is used.</p>
2681
         </li>
2682
         <li>
2683
            <p><i>It is implementation-defined whether the serialization process recovers from serialization 
2684
               errors when the Adaptive output method is used. If it does, it is implementation-defined what 
2685
               error indicator is used. (See 10 Adaptive Output Method)</i></p>
2686
            <p>&#x25BA; Saxon aims to recover from all serialization errors when using the Adaptive output method.
2687
            The effect of a serialization error is highly varied depending on the actual error.</p>
2688
         </li>
2689
         <li>
2690
            <p><i>It is implementation-defined whether, when the Adaptive output method is used, a serializer 
2691
               includes hyperlinks in its output to record the types of atomic values, the bindings of namespace 
2692
               prefixes, the causes of error indicators, and other information. (See 10 Adaptive Output Method)</i></p>
2693
            <p>&#x25BA; Saxon does not include hyperlinks in its output.</p>
2694
         </li>
2695
         
2696
         
2697
         
2698
      </ol>
2699
   </section>
2700
   
2701
   <section id="update" title="XQuery Update 1.0">
2702
      <h1>XQuery Update 1.0</h1>
2703

    
2704

    
2705
      <p>Saxon implements XQuery Update Facility 1.0, which reached Recommendation status on
2706
         17 March 2011. All features, including optional features, are implemented.</p>
2707
      
2708
      <p>The XQuery Update specification defines a number of extensions to the XQuery 1.0 grammar. Saxon
2709
      implements these as extensions to the XQuery 3.1 grammar.</p>
2710

    
2711
      <p>Update is currently supported only on documents built using the <code>linked</code> tree
2712
         model.</p>
2713

    
2714
      <p>There are several limitations worth noting:</p>
2715
      <ul>
2716
         <li>
2717
            <p>The specification requires that updates should be atomic: that is, if any failure
2718
               occurs, the original document is restored to its original state. Saxon meets this
2719
               requirement unless revalidation is requested. If failures occur during the
2720
               revalidation phase, these cannot currently be rolled back. Of course, this only
2721
               affects the in-memory copy of the document; the application should be organized so
2722
               that in this situation it is possible to revert to the copy on disk.</p>
2723
         </li>
2724
         <li>
2725
            <p>The specification requires that node identity should be preserved across updates. The
2726
               extent to which this requirement is met by Saxon is debatable. Saxon allows several
2727
               Java objects to represent the same node. With the linked tree this applies in
2728
               particular to attribute nodes: two requests to get all the attributes of a node will
2729
               return different Java objects, though comparisons using <code>equals()</code> or
2730
                  <code>isSameNodeInfo()</code> will reveal that they refer to the same nodes. After
2731
               an update, it is in general not safe to continue using existing <code>NodeInfo</code>
2732
               objects, and the effect of doing so is undefined. This means that it is impossible to
2733
               determine in any reliable way whether the old nodes have the same identity as the new
2734
               nodes. In practice, with the linked tree implementation, it is safe to continue using
2735
               variables that refer to element nodes (where there is always one Java object per
2736
               node), but it is not safe in the case of attribute nodes.</p>
2737
         </li>
2738
         <li>
2739
            <p>The <code>put()</code> function is implemented using the same run-time support code
2740
               as <code>xsl:result-document</code>, and it currently imposes similar restrictions:
2741
               for example, it must not be called from within a variable initialization or function
2742
               body, and it must to write to a URI that has been read during the execution of the
2743
               query; also, two calls on <code>put()</code> must not write to the same URI. However,
2744
               it does use the XQuery semantics for resolving the relative URI.</p>
2745
         </li>
2746
         <li>
2747
            <p>The specification change introduced by <a
2748
                  href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9432" class="bodylink">bug
2749
                  9432</a>, which is included in the final Recommendation, has not yet been implemented.
2750
               The effect of this is that an updated document may sometimes be missing
2751
               the namespace undeclaration <code>xmlns=""</code> where the specification requires
2752
               it.</p>
2753
         </li>
2754
      </ul>
2755

    
2756
      <p>Saxon does not currently implement XQuery Update 3.0, and there are currently no plans to
2757
         implement it. W3C work on this specification has been discontinued.</p>
2758
   </section>
2759
   <section id="other" title="Conformance with other specifications">
2760
      <h1>Conformance with other specifications</h1>
2761

    
2762

    
2763
      <p>Saxon is dependent on the user-selected XML parser to ensure conformance with the XML 1.0
2764
         or 1.1 Recommendation and the XML Namespaces Recommendation. The syntax for names appearing
2765
         in XPath expressions follows the XML 1.0 or 1.1 rules depending on Saxon configuration
2766
         settings.</p>
2767

    
2768
      <p>Saxon implements the <code>&lt;?xml-stylesheet?&gt;</code> processing instruction as
2769
         described in the W3C Recommendation <i>Associating StyleSheets with XML Documents</i>. The
2770
            <code>href</code> pseudo-attribute must be a URI identifying an XML document containing
2771
         a stylesheet, or a URI with a fragment identifier identifying an embedded stylesheet. The
2772
         fragment must be the value of an <code>ID</code> attribute declared as such in the DTD.</p>
2773

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

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

    
2788
      <p>Saxon on the Java platform should work with any DOM-conformant XML parser, however, Saxon's
2789
         DOM interface is tested only with the DOM implementation included in the Oracle JDK, and
2790
         other DOM implementations are known to vary. Saxon has been used successfully with the
2791
         Oracle XDK DOM implementation, though this is not included in the standard test suite and
2792
         problems have occasionally been reported with this combination.</p>
2793

    
2794
      <p>When a XOM tree is supplied as the transformation input, Saxon does not combine adjacent
2795
         text nodes into a single node. Adjacent text nodes can occur as the result of user
2796
         modifications to the tree, or as a result of the presence of CDATA sections or entity
2797
         references, depending on the options in force when the tree was constructed. <i>This
2798
            restriction no longer applies to DOM and JDOM trees: in these cases, the virtual XPath
2799
            view that is created maps one XPath text node to a sequence of adjacent DOM or JDOM
2800
            nodes.</i></p>
2801
   </section>
2802
   <section id="encodings" title="Character Encodings Supported">
2803
      <h1>Character Encodings Supported</h1>
2804

    
2805

    
2806
      <p>The encodings supported on input depend entirely on your choice of XML parser.</p>
2807

    
2808
      <p>On output, any encoding supported by the Java VM or the .NET platform (as appropriate) may
2809
         be used.</p>
2810

    
2811
      <p>A list of the character encodings supported by the Java VM can be obtained by using the
2812
         command <code>java net.sf.saxon.charcode.CharacterSetFactory</code>, with no
2813
         parameters.</p>
2814
   </section>
2815
   <section id="jaxp" title="JAXP Conformance">
2816
      <h1>JAXP Conformance</h1>
2817

    
2818

    
2819
      <p>Saxon on the Java platform implements the JAXP 1.3 API, and selected features of later
2820
         versions. Since JDK 1.5 the JAXP API has been available as a standard part of the Java
2821
         platform, and it provides access to XSLT transformation, schema validation, and XPath
2822
         processing services.</p>
2823

    
2824
      <p>The JAR files for Saxon-HE, Saxon-PE, and Saxon-EE contain in their manifests the service
2825
         provider configuration files needed to identify Saxon as an XSLT processor, and Saxon-EE
2826
         contains the manifest to identify itself as an XSD schema processor. This means that if
2827
         Saxon is on the classpath, applications using the JAXP service discovery API may pick up
2828
         Saxon as the XSLT or Schema processor whether this is explicitly requested or not. Saxon no
2829
         longer identifies itself as an XPath provider. This is because applications using the JAXP
2830
         API to request an XPath processor have often not been validated with Saxon, and can fail as
2831
         a result (for example, because they are expecting an XPath 1.0 processor rather than a 2.0
2832
         processor). Applications wanting to use Saxon as their XPath provider must therefore
2833
         request it explicitly.</p>
2834

    
2835
      <p>Saxon implements the interfaces in the <code>javax.xml.transform</code> package in full,
2836
         including support for SAX, DOM, and Stream input, and SAX, DOM, and Stream output.</p>
2837
      
2838
      <p>It should be noted that there are many points of detail where JAXP is under-specified. Some of
2839
      these areas include:</p>
2840

    
2841
      <ul>
2842
         <li>The types of values that can be supplied as transformation parameters.</li>
2843
         <li>The exact sequence of SAX events that can be supplied to a <code>TemplatesHandler</code>
2844
         or <code>TransformerHandler</code> (the SAX specification says the sequence of events
2845
         emitted by an <code>XMLReader</code> depends on various configuration settings of the 
2846
         <code>XMLReader</code>).</li>
2847
         <li>The extent to which the information passed across the API is validated (for example,
2848
         whether names of elements and attributes are checked for conformity to the XML naming rules).</li>
2849
      </ul>
2850
      
2851
      <p>In such areas, the Javadoc for the Saxon implementation of JAXP interfaces supplies
2852
      additional information about Saxon's interpretation of the JAXP specification.</p>
2853

    
2854
      <p>Saxon implements the XPath API (the interfaces in the <code>javax.xml.xpath</code> package)
2855
         in full. Note however that the <code>XPathException</code> exception used throughout Saxon
2856
         is unrelated to the class of the same name defined in the XPath API. The Saxon XPath API
2857
         works with several object models: DOM, JDOM, XOM, DOM4J, Axiom, and the native Saxon object
2858
         model.</p>
2859

    
2860
      <p>The JAXP 1.3 XPath API is designed primarily for use with XPath 1.0. Saxon implements it
2861
         with XPath 2.0 and XPath 3.1. This means that decisions were necessary on how to handle the richer set of
2862
         return types available with 2.0. If the return type requested is String, Number, or
2863
         Boolean, then Saxon converts the result to one of these types as if by using the XPath
2864
         functions <code>string()</code>, <code>number()</code>, or <code>boolean()</code>. Items
2865
         after the first in the atomized sequence are discarded. If the return type requested is
2866
            <code>NODE</code>, Saxon returns the first item in the result sequence if it is a node,
2867
         and reports an error if it is an atomic value. If the result sequence is empty, it returns
2868
         null. If the return type requested is <code>NODELIST</code>, Saxon returns a Java List
2869
         containing all the items in the sequence, whether they are nodes or not, except in the case
2870
         where the result consists of DOM Nodes, in which case a DOM NodeList is returned. Nodes are
2871
         returned using the native node object in the input data model; atomic values are returned
2872
         using the most appropriate Java class. Note that in the case of numeric results, it is not
2873
         always easy to predict whether the result will be a Long, a Double, or a BigDecimal, and it
2874
         is advisable to cast the data to one of the numeric types within the XPath expression to
2875
         make the result predictable.</p>
2876

    
2877
      <p>Saxon-EE also implements the JAXP 1.3 Validation API. This allows a schema to be parsed and
2878
         validated, and provides two mechanisms for validating a document against a schema: the
2879
            <code>Validator</code> and the <code>ValidatorHandler</code>.</p>
2880

    
2881
      <p>There are some minor non-conformances in the Saxon implementation of this interface:</p>
2882
      <ul>
2883
         <li>
2884
            <p>The interface specification restricts the types of <code>Source</code> and
2885
                  <code>Result</code> object that can be supplied to a <code>Validator</code>. Saxon
2886
               does not enforce these restrictions, it allows any kind of <code>Source</code> and
2887
                  <code>Result</code> that a <code>Transformer</code> would accept.</p>
2888
         </li>
2889
         <li>
2890
            <p>Saxon's implementation of <code>ValidatorHandler</code> performs more buffering of
2891
               events than is permitted by the specification.</p>
2892
         </li>
2893
         <li>
2894
            <p>The method <code>isSpecified(int)</code> in the <code>TypeInfoProvider</code> always
2895
               returns true.</p>
2896
         </li>
2897
      </ul>
2898

    
2899
      <p>In addition, Saxon implements part of the <code>javax.xml.parsers</code> API. Saxon no
2900
         longer provides its own SAX parser, however it does provide a <code>DocumentBuilder</code>.
2901
         The DOM interfaces are limited by the capabilities of the Saxon DOM, specifically the fact
2902
         that it is read-only. Nevertheless, the <code>DocumentBuilder</code> may be used to
2903
         construct a Saxon tree, or to obtain an empty Document node which can be supplied in a
2904
         DOMResult to hold the result of a transformation.</p>
2905

    
2906
      <aside>Although JAXP offers the potential for applications to avoid lock-in to specific XSLT
2907
         or XSD processors, this is difficult to achieve in practice while taking full advantage of
2908
         Saxon's capabilities. For example, Saxon operates much more efficiently using its own
2909
         internal tree model than when using the DOM (sometimes by a factor of ten). Therefore
2910
         Saxon's <b>s9api</b> interface is recommended in preferance to JAXP.</aside>
2911
   </section>
2912
   <section id="xqj" title="XQJ Conformance">
2913
      <h1>XQJ Conformance</h1>
2914

    
2915

    
2916
      <p>Saxon implements XQJ, the XQuery API for Java defined in <a
2917
            href="http://www.jcp.org/en/jsr/detail?id=225" class="bodylink">JSR 225</a>. The current
2918
         version that is implemented is the Final Release dated March 2009, which was publicly
2919
         announced on 24 June 2009.</p>
2920

    
2921
      <aside>XQJ is made available under an Oracle license which is not OSI-compliant because it
2922
         does not permit modifications. Some users have policies that only allow OSI-compliant
2923
         licenses. For this reason, in Saxon-HE the XQJ support code is included in a separate JAR
2924
         file, which users can adopt or discard at their discretion.</aside>
2925

    
2926
      <p>The compliance definition for XQJ (section 3 of the specification) requires a statement of
2927
         how all aspects of the specification that are implementation-defined have been implemented.
2928
         The following table provides this statement for the Saxon implementation.</p>
2929
      <table>
2930
         <tr>
2931
            <td>
2932
               <p>
2933
                  <strong>Implementation-defined feature</strong>
2934
               </p>
2935
            </td>
2936
            <td>
2937
               <p>
2938
                  <strong>Saxon implementation</strong>
2939
               </p>
2940
            </td>
2941
         </tr>
2942
         <tr>
2943
            <td>
2944
               <p> The class name of the <code>XQDataSource</code> implementation </p>
2945
            </td>
2946
            <td>
2947
               <p>&#x25BA; 
2948
                  <code>net.sf.saxon.xqj.SaxonXQDataSource</code>
2949
               </p>
2950
            </td>
2951
         </tr>
2952
         <tr>
2953
            <td>
2954
               <p> All properties defined on the <code>XQDataSource</code> implementation </p>
2955
            </td>
2956
            <td>
2957
               <p>&#x25BA;  The following properties are defined: allowExternalFunctions, dtdValidation,
2958
                  expandAttributeDefaults, expandXInclude, retainLineNumbers, schemaValidationMode,
2959
                  stripWhitespace, useXsiSchemaLocation, xmlVersion, xsdVersion. </p>
2960
            </td>
2961
         </tr>
2962
         <tr>
2963
            <td>
2964
               <p> The syntax and semantics for commands, assuming executing commands through
2965
                     <code>XQExpression</code> is supported. </p>
2966
            </td>
2967
            <td>
2968
               <p>&#x25BA;  No commands are supported (only XQuery expressions). </p>
2969
            </td>
2970
         </tr>
2971
         <tr>
2972
            <td>
2973
               <p> Is cancelling of query execution supported? </p>
2974
            </td>
2975
            <td>
2976
               <p>&#x25BA;  No, query execution cannot be cancelled. </p>
2977
            </td>
2978
         </tr>
2979
         <tr>
2980
            <td>
2981
               <p> The default and supported values for each parameter described in XQuery
2982
                  Serialization </p>
2983
            </td>
2984
            <td>
2985
               <p>&#x25BA;  Although this is implementation-defined, the test suite makes some assumptions
2986
                  and these have been followed. The defaults are: byte-order-mark="no"
2987
                  cdata-section-elements="" doctype-public=null doctype-system=null encoding="utf-8"
2988
                  indent="yes" media-type="application/xml" method="xml" normalization-form="none"
2989
                  omit-xml-declaration="yes" standalone="omit" undeclare-prefixes="no"
2990
                  use-character-maps="" version="1.0" </p>
2991
            </td>
2992
         </tr>
2993
         <tr>
2994
            <td>
2995
               <p> Additional StAX or SAX event types being reported, beside the event types
2996
                  documented in [the] specification </p>
2997
            </td>
2998
            <td>
2999
               <p>&#x25BA;  None. </p>
3000
            </td>
3001
         </tr>
3002
         <tr>
3003
            <td>
3004
               <p> Support for XDM instances and types based on user-defined schema types </p>
3005
            </td>
3006
            <td>
3007
               <p>&#x25BA;  When used with Saxon-EE, user-defined schema types are supported, to the extent
3008
                  that the XQJ interface allows them to be used. </p>
3009
            </td>
3010
         </tr>
3011
         <tr>
3012
            <td>
3013
               <p> The semantics with respect to node identity, document order, and full node
3014
                  context, when a node is bound to an external variable. </p>
3015
            </td>
3016
            <td>
3017
               <p>&#x25BA;  When a node is bound to an XQItem and hence to a variable in a query, node
3018
                  identity, document order, and "context" (relationships to other nodes) are
3019
                  maintained. </p>
3020
            </td>
3021
         </tr>
3022
         <tr>
3023
            <td>
3024
               <p> Is login timeout supported? </p>
3025
            </td>
3026
            <td>
3027
               <p>&#x25BA;  No. (There is no concept of login.) </p>
3028
            </td>
3029
         </tr>
3030
         <tr>
3031
            <td>
3032
               <p> Are transactions supported? </p>
3033
            </td>
3034
            <td>
3035
               <p>&#x25BA;  No. Saxon only supports read-only query via the XQJ interface. </p>
3036
            </td>
3037
         </tr>
3038
         <tr>
3039
            <td>
3040
               <p> Behaviour of the <code>getNodeUri()</code> method, defined on
3041
                     <code>XQItemAccessor</code>, for other than document nodes. </p>
3042
            </td>
3043
            <td>
3044
               <p>&#x25BA;  The method is defined on any node, and returns the URI of the external entity in
3045
                  which the containing element originally appeared, if known, or the empty URI
3046
                  otherwise. </p>
3047
            </td>
3048
         </tr>
3049
         <tr>
3050
            <td>
3051
               <p> Behaviour of the <code>getTypeName()</code> method, defined on
3052
                     <code>XQItemType</code>, for anonymous types. </p>
3053
            </td>
3054
            <td>
3055
               <p>&#x25BA;  Anonymous types have a system-generated name. </p>
3056
            </td>
3057
         </tr>
3058
         <tr>
3059
            <td>
3060
               <p> Behaviour of the <code>getSchemaURI()</code> method, defined on
3061
                     <code>XQItemType</code>
3062
               </p>
3063
            </td>
3064
            <td>
3065
               <p>&#x25BA;  The system identifier (document URI) of the original schema document is reported
3066
                  if the information is available. </p>
3067
            </td>
3068
         </tr>
3069
         <tr>
3070
            <td>
3071
               <p> Behaviour of the <code>createItemFromDocument()</code> methods, defined on
3072
                     <code>XQDataFactory</code>, if the specified value is not a well-formed XML
3073
                  document. </p>
3074
            </td>
3075
            <td>
3076
               <p>&#x25BA;  An exception is thrown. </p>
3077
            </td>
3078
         </tr>
3079
         <tr>
3080
            <td>
3081
               <p> Behaviour of the <code>bindDocument</code> methods, defined on
3082
                     <code>XQDynamicContext</code>, if the specified value is not a well-formed XML
3083
                  document. </p>
3084
            </td>
3085
            <td>
3086
               <p>&#x25BA;  An exception is thrown. </p>
3087
            </td>
3088
         </tr>
3089
         <tr>
3090
            <td>
3091
               <p> The error codes, reported through <code>XQQueryException</code>, in addition to
3092
                  the standard error codes listed in [XQuery] and its associated specifications.
3093
               </p>
3094
            </td>
3095
            <td>
3096
               <p>&#x25BA;  None. The Saxon implementation does not currently use the class
3097
                     <code>XQQueryException</code>. </p>
3098
            </td>
3099
         </tr>
3100
      </table>
3101
      <aside>Section 19 of the XQJ specification ("Interoperability") suggests that an XQJ
3102
         implementation should accept items and built-in types that were created using a different
3103
         vendor's XQJ implementation. In general, Saxon will only handle the Saxon implementation of
3104
         XQJ interfaces. At any rate, it has not been validated with third-party implementations.
3105
      </aside>
3106
   </section>
3107
   
3108
</article>
(6-6/21)