Project

Profile

Help

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

he / src / userdoc / changes / changes-9.8.xml @ d9cb5c62

1
<?xml version="1.0" encoding="UTF-8"?>
2

    
3
<release number="9.8" date="2017-06-08" xmlns="http://www.saxonica.com/ns/doc/changes">
4

    
5

    
6
    <category name="command-line">
7
        
8
        <p>The <code>-opt</code> flag on the <code>Transform</code> and <code>Query</code> command line has been reorganized. Integer values 0 (no optimization)
9
        and 10 (full optimization) are still recognized for compatibility, but the flag now allows individual optimizations to be enabled or
10
        disabled selectively. There is a set of single-letter flags identifying particular optimizations (c: generate bytecode; f: inline functions;
11
        g: extract global variables; j: just-in-time compilation (of XSLT template rules); k: create keys; l: loop lifting; m: miscellaneous; s: extract common subexpressions; v: inline variables;
12
        w: create switch statements; x: index predicates). A value such as <code>-opt:gs</code> runs with only the selected
13
            optimizations; while <code>-opt:-gs</code> runs with the selected optimizations disabled and all others enabled.</p>
14
        
15
        <p>The <code>-xsl</code> option on the Transform command line is restored to its pre-9.7 setting where it contains a single filename, being the
16
        top level module of the stylesheet. If additional library packages are used, these may be specified either in a configuration file (preferred),
17
        or listed in the new <code>-lib</code> option, whose value is a list of filenames separated by ";" on Windows or ":" on Linux/Mac. Each filename
18
        may be either the top-level module of a source XSLT package, or a SEF file produced by exporting a library package.</p>
19
        
20
        <p>The Transform and Query commands have new options related to tracing: <code>-Tout:filename</code> specifies the destination for -T trace output; 
21
            while <code>-Tlevel:(none|low|normal|high)</code>
22
            controls the level of detail in the output:</p>
23
        
24
        <ul>
25
            <li>none: no output</li>
26
            <li>low: traces entry and exit to user-defined functions and templates</li>
27
            <li>normal: traces "instructions" (in the XSLT sense, or in XQuery, expressions at a similar level of granularity)</li>
28
            <li>high: traces "expressions" (not fully implemented)</li>
29
        </ul>
30
        
31
        <p>The same functionality is available via API and configuration options.</p>
32
        
33
        <p>The <code>-relocate</code> command line option for <code>Transform</code> is added, to produce an export package
34
            which can be deployed to a different location, with a different base URI.</p>
35
        
36

    
37
 
38
    </category>
39
    <category name="xslt30">
40
        
41
      <p>XSLT 3.0 is now supported from Saxon-HE upwards. All Saxon editions support the basic conformance level. Other optional conformance features
42
          are supported as follows:</p>
43
        
44
        <ul>
45
            <li>Schema-Awareness: EE only</li>
46
            <li>Serialization: HE, PE, and EE</li>
47
            <li>1.0 Compatibility: PE and EE (see below)</li>
48
            <li>Streaming: EE only</li>
49
            <li>Dynamic Evaluation (xsl:evaluate): PE and EE</li>
50
            <li>Higher-order Functions: PE and EE</li>
51
            <li>XPath 3.1 support: HE, PE, and EE</li>
52
        </ul>
53
        
54
        <p>Previous Saxon releases supported 1.0 Compatibility mode in Saxon-HE as well as PE and EE. This support has been dropped. Users still running
55
        1.0 stylesheets therefore have three options:</p>
56
        
57
        <ul>
58
            <li>Convert the stylesheets to 2.0/3.0 (this usually requires little or no change, but it does require testing to ensure that everything still works)</li>
59
            <li>Upgrade to Saxon-PE</li>
60
            <li>Stick with Saxon-HE 9.7 for the time being</li>
61
        </ul>
62
        
63
        <aside>We would like eventually to drop support for 1.0 compatibility mode from the product entirely. This change is the first step in this process.</aside>
64
        
65
      <p>The <code>xsl:stream</code> instruction has been generalized to
66
          <a class="bodylink code" href="/xsl-elements/source-document">xsl:source-document</a>. For the time being <code>xsl:stream</code>
67
      is still recognized, and is interpreted as <code>&lt;xsl:source-document streamable="yes"&gt;</code>.</p>
68
        
69
        <p>Streamable stylesheet functions are implemented, as defined in the XSLT 3.0 specification. The test coverage for this feature is somewhat sparse,
70
        so the implementation might turn out to need more work.</p>
71
        
72
        <p>Type checking on maps has been improved. In particular, the static type of the expression <code>map:get(M, K)</code> (or equivalent
73
        constructs such as <code>M(K)</code> or <code>M?K</code> is now deduced from the type of the map if known. The checking is even
74
        stronger if the new (Saxon-specific) mechanism of tuple types is used: see 
75
            <a class="bodylink" href="/extensions/syntax-extensions/tuple-types">Tuple Types</a>.</p>
76
 
77
    </category>
78
    
79
    <category name="xslt20">
80
        
81
        <p>Support for XSLT 2.0 is dropped, in the sense that there is no longer a mode of operation that accepts XSLT 2.0 syntax while
82
        rejecting XSLT 3.0 syntax. The level of backwards compatibility in XSLT 3.0 is very high, so it should still be possible to run
83
        XSLT 2.0 stylesheets under Saxon without difficulty; the only real impact of this change is that it is not possible to run XSLT 2.0 
84
        conformance tests that expect all errors against the 2.0 specification to be detected.</p>
85
       
86
    </category>
87
    
88
    <category name="xpath30">
89
        
90
        <p>Saxon 9.8 drops support for XPath 3.0. When running in XPath 3.1 mode, valid XPath 3.1 expressions are evaluated with a very
91
        high level of backwards compatibility.</p>
92
        
93
    </category>
94

    
95
    <category name="xpath31">
96
        
97
        <p>The specification requires the functions <code>unparsed-text()</code>, <code>unparsed-text-lines()</code>, and
98
        <code>unparsed-text-available()</code> to be stable: that is, repeated calls within a single query or stylesheet execution
99
        are required to return the result. Achieving this is expensive, because it means saving the results in memory just in case
100
        they are needed again. Previous Saxon releases did not attempt to satisfy this requirement. In Saxon 9.8 it can be achieved
101
        at user option, by setting the configuration property <code
102
            java="net.sf.saxon.lib.FeatureKeys#STABLE_UNPARSED_TEXT">STABLE_UNPARSED_TEXT</code>. For performance reasons, the default
103
        remains that the results are not stable (that is, if the file contents change dynamically, a second call will return different
104
        results from the first).</p>
105
  
106
    </category>
107
    
108
    <category name="xquery10">
109
        
110
        <p>Support for XQuery 1.0 and XQuery 3.0 is dropped (that is, there is no longer any way to run Saxon as an XQuery 1.0 or XQuery 3.0
111
            processor, in such a way that later language features are rejected). XQuery 1.0 and 3.0 queries will continue to run, because
112
            there is a high level of backwards compatibility in XQuery 3.1.
113
        </p>
114
  
115
    </category>
116
        
117
        <category name="xquery30">
118
            
119
            <p>Support for XQuery 1.0 and XQuery 3.0 is dropped (that is, there is no longer any way to run Saxon as an XQuery 1.0 or XQuery 3.0
120
                processor, in such a way that later language features are rejected). XQuery 1.0 and 3.0 queries will continue to run, because
121
                there is a high level of backwards compatibility in XQuery 3.1.
122
            </p>
123
            
124
        </category>
125
    
126
    <category name="xquery31">
127
        
128
        <p>Added more command line options related to tracing: <code>-Tout:filename</code> specifies the destination for -T trace output; 
129
            while <code>-Tlevel:(none|low|normal|high)</code> controls the level of detail in the output. The same functionality
130
            is available via API and configuration options. For more information see <a class="bodylink" href="/configuration/config-features">Configuration Features</a>.</p>
131
        
132
        <p>When the <code>-qs</code> option is used on the command line, the static base URI of the query is the current working
133
            directory. (See <a href="/using-xquery/commandline" class="bodylink">Running XQuery from the Command Line</a>.)</p>
134
        
135
        <p>Type checking on maps has been improved. In particular, the static type of the expression <code>map:get(M, K)</code> (or equivalent
136
            constructs such as <code>M(K)</code> or <code>M?K</code> is now deduced from the type of the map if known. The checking is even
137
            stronger if the new (Saxon-specific) mechanism of tuple types is used: see 
138
            <a class="bodylink" href="/extensions/syntax-extensions/tuple-types">Tuple Types</a>.</p>
139
        
140
        <p>Annotations on functions, including annotation assertions, are now fully supported. The annotation information is now retained
141
        as a property of a function and its type. Multiple annotations with the same name are allowed (which requires some change to internal
142
        data structures). The <code>Configuration</code> allows a <code>FunctionAnnotationHandler</code> to be registered for a
143
            particular annotation
144
        namespace; this handler is invoked to determine whether functions having particular annotations satisfy or fail to satisfy 
145
        particular annotation assertions in that namespace.</p>
146
        
147
        <p>The new extension function <a class="bodylink code"
148
            href="/functions/saxon/function-annotations">saxon:function-annotations()</a> is made available to obtain access to the annotations
149
        defined in a function declaration.</p>
150
        
151
        <p>A user-defined function in XQuery may now be designated as a memo function by using an annotation: 
152
            <code>declare %saxon:memo-function local:f....</code>. Option declarations may continue to be used for the
153
        same purpose, for backwards compatibility.</p>
154
        
155
 
156
    </category>
157

    
158
    <category name="functions31">
159
        
160
        <p>The <code>serialize-json()</code> function, which was defined in early working drafts of the specification, has been dropped.
161
            Use <a class="bodylink code" href="/functions/fn/serialize">serialize()</a> with appropriate options in the second argument.</p>
162
        
163
        <p>The <a class="bodylink code" href="/functions/array/put">array:put()</a> function has been added.</p>
164
        
165
        <p>The signature of <a class="bodylink code" href="/functions/fn/sort">fn:sort()</a> and <a class="bodylink code"
166
            href="/functions/array/sort">array:sort()</a> has changed: the second argument is now a collation URI,
167
            and the comparison function becomes the third argument.</p>
168
        
169
        <p>A new function <a class="bodylink code" href="/functions/map/find">map:find()</a> is available.</p>
170
        
171
        <p>The implementation of <a class="bodylink code" href="/functions/fn/transform">fn:transform()</a> has been brought into
172
            line with the final W3C specification; there are significant changes.</p>
173
 
174
    </category>
175

    
176
    <category name="installation">
177
        <p>A new Configuration option 
178
            <code java="net.sf.saxon.lib.FeatureKeys#DEFAULT_REGEX_ENGINE">FeatureKeys.DEFAULT_REGEX_ENGINE</code> is supported.
179
        The value indicates which regular expression engine will be used for evaluating regular expressions in XPath functions
180
        such as <code>matches()</code>, XSLT instructions such as <code>&lt;xsl:analyze-string&gt;</code>, and in XSD pattern
181
            facets. The possible values are "S" (the default) indicating the Saxon regular expression engine (derived from Apache Jakarta), "J"
182
 for the Java JDK regex engine, and "N" for the Microsoft .NET regex engine (available on the .NET platform only). When
183
 the options "J" or "N" are used, regular expressions must follow the syntax and semantics of the chosen engine, rather than the
184
 W3C XPath and XSD rules.</p>
185
        
186
        <p>The particular trigger for adding this option was a user's need to do validation using schemas written for the 
187
        Microsoft XSD processor, which uses Microsoft's regex dialect in its pattern facet rather than the W3C regex dialect.
188
        There is no guarantee that this makes Saxon's XSD processor bug-compatible with Microsoft's processor in every respect,
189
        but it brings it closer.</p>
190
        
191
        <p>New configuration options have been added allowing the <code>UnparsedTextURIResolver</code> (used for dereferencing
192
        URIs passed to <code>unparsed-text()</code> and related functions) to be set at Configuration level, including
193
        via the Configuration file.</p>
194
        
195
        <p>There is a new configuration option <code
196
            java="net.sf.saxon.lib.FeatureKeys#MAX_COMPILED_CLASSES">FeatureKeys.MAX_COMPILED_CLASSES</code> to put a cap on the
197
            number of classes compiled when bytecode generation is
198
        enabled. This is to prevent the situation where the cost of generating such classes, and the memory they occupy,
199
        starts to exceed any benefit. The default value is 10,000 (ten thousand). If the limit is exceeded, Saxon falls back
200
        to using interpreted mode for any remaining functions or templates that have not yet been compiled. The limit applies
201
        to the entire VM, not just to one <code>Configuration</code>.</p>
202
    </category>
203
        
204
        <category name="external-object-models">
205
            <p>With a wrapped DOM document, the <a class="bodylink code" href="/functions/fn/id">id()</a> function now recognizes
206
                <code>xml:id</code> attributes whether or not the underlying DOM does so.</p>
207
            
208
            <p>A new tree model called the Domino model is introduced for handling DOM documents. This is available
209
            in Saxon-EE only. It offers substantial performance improvements when the input to a query or transformation
210
            is supplied in the form of a DOM, and is therefore the default way of handled DOM input in Saxon-EE.
211
            Further details are available at <a class="bodylink code" href="/sourcedocs/domino">The Domino Tree Model</a>.</p>
212
        </category>
213

    
214
    <category name="serialization">
215
        
216
        <p>The product specification has always stated that Saxon-specific serialization properties such as <code>saxon:indent-spaces</code>
217
        are not available in Saxon-HE; this was previously checked on some interfaces and not on others, and varied from one property
218
        to another. It is now checked more systematically. In some cases use of these properties is an error,
219
        in other cases they will be ignored, depending on the interface in question.</p>
220
     
221
    </category>
222

    
223
    <category name="streaming">
224
        
225
        <p>The implementation of the <a class="bodylink code" href="/functions/saxon/stream">saxon:stream()</a> extension function
226
            (and the equivalent <code>saxon:stream</code>
227
        pragma) has been simplified: it is now rewritten directly into an <a class="bodylink code"
228
            href="/xsl-elements/source-document">xsl:source-document</a> instruction.</p>
229
        
230
        <p>The streaming code has been improved so that it is much less inclined to make copies of subtrees where these are not
231
            needed, even when an <code>&lt;xsl:copy-of&gt;</code> instruction is used. For example, <code>&lt;xsl:copy-of&gt;</code>
232
            as a child of an element constructor instruction is now implemented as <code>&lt;xsl:sequence&gt;</code> (by sending incoming
233
            SAX parser events straight to the output destination). This can greatly reduce memory requirements, especially for
234
            grouping applications.</p>
235
        
236
        <p>When parsing of the source document finishes early because no further input is required, a <code>QuitParsingException</code>
237
        is now notified to the <code>warning()</code> method of the registered <code>ErrorListener</code>. This can usually be ignored;
238
        but it is sometimes useful to know that the source file has not been read to completion (which means, for example, that it has
239
        not been completely validated).</p>
240
        
241
        <p>Streaming stylesheet functions are now implemented.</p>
242
        
243
        <p>The concept of streaming extensions has been dropped. Saxon now aims to conform to the XSLT 3.0 streamability rules with
244
            no restrictions and no extensions. However, Saxon still checks streamability after optimization has been performed, which
245
            may sometimes result in non-streamable code being rewritten in a way that is streamable, for example when non-streamable
246
            constructs are completely optimized away.</p>
247
        
248
        <p>The (partial) implementation of "crawling" streamability in instructions such as <code>xsl:apply-templates</code> and <code>xsl:for-each-group</code>
249
        has therefore been dropped. In accordance with the XSLT 3.0 specification, Saxon now requires the select expression of such instructions
250
        to be striding: that is, the select expression can use the child axis but not the descendant axis.</p>
251
        
252
        
253
       
254

    
255
    </category>
256
        
257
        <category name="JAXP">
258
            <p>It is now possible to run streaming XSLT 3.0 transformations using the JAXP API. The <code>TransformerFactory</code>
259
                used must be an instance of <code
260
                    java="com.saxonica.config.StreamingTransformerFactory">com.saxonica.config.StreamingTransformerFactory</code>. If the stylesheet is streamable
261
                (more specifically if the initial mode is declared with <code>&lt;xsl:mode streamable="yes"/></code>), then the <code>Transformer.transform()</code>
262
            method, if given a <code>SAXSource</code> or <code>StreamSource</code> as its argument, will process the input document using streaming.
263
            Under these circumstances the source document will not be available as the global context item: that is, any reference to the context item
264
            "." within a global variable declaration is a dynamic error.</p>
265
            
266
            <p>The <code>newTransformerHandler()</code> method of the <code>StreamingTransformerFactory</code> delivers an implementation of
267
            <code>TransformerHandler</code> that can be used to run a streamed transformation. After calling <code>setResult()</code> to set the
268
            destination of the transformation, the streamed input to the transformation can be supplied as a sequence of SAX <code>ContentHandler</code>
269
            method calls, for example <code>startElement()</code> and <code>endElement()</code>.</p>
270
        </category>
271

    
272
    <category name="spi">
273
        <p>The old class <code>net.sf.saxon.value.DecimalValue</code> has been renamed <code>net.sf.saxon.value.BigDecimalValue</code>,
274
        and is now a subclass of a new abstract class <code>net.sf.saxon.value.DecimalValue</code> which also has
275
        <code>net.sf.saxon.value.IntegerValue</code> as a subclass. This gives a closer correspondence between the Java class
276
        hierarchy and the XDM type hierarchy; it reflects the fact that <code>xs:integer</code> is a subtype of <code>xs:decimal</code>.
277
        The specific trigger for the change is to make reflexive extension functions with arguments declared with types such as
278
        <code>OneOrMore&lt;DecimalValue&gt;</code> work correctly when the supplied argument value is an integer.</p>
279
        
280
        <p>Continuing the gradual removal of functionality from the global <code java="net.sf.saxon.om.NamePool">NamePool</code>,
281
            the <code>NamePool</code> is no longer responsible
282
        for managing namespace prefixes, and these are now handled by each document model in its own way. Integer namecodes (with
283
        the prefix code in the top 10 bits) are still used in the tiny tree, but nowhere else. As a result, the <code>getNameCode()</code>
284
            method has disappeared from the <code>NodeInfo</code> interface. To compare names efficiently, use <code
285
                java="net.sf.saxon.om.NodeInfo#getFingerprint">NodeInfo.getFingerprint()</code>.</p>
286
        
287
        <p>A consequence of the change is that the limit of 1024 prefixes per URI globally has been replaced by a limit of 1024 distinct prefixes
288
        declared in each TinyTree document.</p>
289
        
290
        <p>Another consequence is that when Saxon needs to allocate an arbitrary prefix to go with a particular URI (for example, when generating
291
        an attribute node during schema validation), it is no longer able to turn to the <code>NamePool</code> to find prefixes that have previously been used with
292
        that URI. It therefore generates an arbitrary string. However, it is still possible to configure a preferred prefix for a URI manually,
293
        using the call <code>configuration.getNamePool().suggestPrefix(prefix, uri)</code>.</p>
294
        
295
        <p>The marker interface <code>FingerprintedNode</code> has been removed; the <code>NodeInfo</code> interface now defines
296
        methods <code>hasFingerprint()</code> and <code>getFingerprint()</code> which must be provided by all implementations. <code>NodeInfo</code>
297
        implementations that do not use <code>NamePool</code> fingerprints should return <code>false</code> for <code>hasFingerprint()</code>,
298
        and should throw an <code>UnsupportedOperationException</code> for <code>getFingerprint()</code>. The reason for this change
299
        is that fingerprints were not being used for "wrapper" nodes such as a virtual copy, a snapshot, or a space-stripped copy of
300
        an underlying node even where a the underlying node has a fingerprint.</p>
301
        
302
        <p>The <code>namespace()</code> method of the <code java="net.sf.saxon.event.Receiver">Receiver</code> interface now
303
            accepts a <code java="net.sf.saxon.om.NamespaceBindingSet">NamespaceBindingSet</code>, which
304
            is a generalization of the previous <code>NamespaceBinding</code> object, allowing multiple namespace bindings to be passed in a single call.
305
            This was done to improve performance of shallow copy: see bug 3011.</p>
306
        
307
        <p>On various APIs, Saxon checks that supplied nodes belong to the right <code>Configuration</code>. This check is now
308
        applied to all nodes, whether or not they use <code>NamePool</code> fingerprints. (Previously the check was being omitted
309
        for "wrapper" nodes, even though they might use node fingerprints and therefore be tied to a <code>NamePool</code>.)</p>
310
        
311
        <p>The <code java="net.sf.saxon.ma.map.MapItem">MapItem</code> interface, representing an XDM map item, has been changed,
312
            to reflect W3C specification changes
313
        and usage experience. A map is now context-free and error-free. There is now a <code>conforms()</code> method to test
314
        whether the map conforms to a given type. The type information that is maintained internally (in the <code>HashTrieMap</code>
315
        implementation class) has been changed to eliminate the need for a dependency on the Saxon <code>Configuration</code>. This has enabled
316
            the provision of a context-free <code java="net.sf.saxon.s9api.XdmMap">XdmMap</code> class at the s9api level.</p>
317
        
318
        <p>The class <code>net.sf.saxon.dom.DocumentBuilderImpl</code> has been dropped, in the belief that the class was
319
            obsolete and unused. There were no references to the class in the code and no unit tests.</p>
320
        
321
        <p>The machinery for evaluating queries in "pull event" mode has been dismantled, as it had become
322
        redundant. The <code>PullEventSource</code>, <code>PullEvent</code>, and <code>EventIterator</code> classes and their 
323
            subclasses have all gone; the method <code>Expression.iterateEvents()</code> has gone,
324
        and the <code>XQueryExpression.pull()</code> method is now a deprecated synonym for the <code>run()</code> method. The
325
            configuration property <code>FeatureKeys.LAZY_CONSTRUCTION</code> is no longer recognized. There
326
        is some residual support for <code>EventIterator</code> objects, but only to the extent needed to support XQJ interfaces.</p>
327
        
328
        <p>A <code java="net.sf.saxon.event.Receiver">Receiver</code> supplied to process <code>xsl:message</code> output is now
329
            able to determine the error code specified
330
        in the <code>xsl:message/@error-code</code> attribute. This is made available by sending a <code>processingInstruction</code> event
331
        to the message listener, immediately after the <code>startDocument</code> event. The processing instruction has the target (name) property
332
        set to "error-code", and the data (value) property set to an EQName representation of the error code. The default message listener
333
        ignores this processing instruction, for backwards compatibility. At the s9api level, if a <code
334
            java="net.sf.saxon.s9api.MessageListener">MessageListener</code> is supplied,
335
            the processing instruction is discarded for compatibility reasons, but the new <code
336
                java="net.sf.saxon.s9api.MessageListener2">MessageListener2</code> interface allows
337
        the error code to be reported.</p>
338
  
339
    </category>
340

    
341
    <category name="extensions">
342
        <h2>Extension Functions</h2>
343
        
344
        <p>The extension function <code>saxon:sort()</code> is dropped, as it is superseded by <code>fn:sort()</code> in XPath 3.1.</p>
345
        
346
        <p>A new extension function <a class="bodylink code" href="/functions/saxon/doc">saxon:doc()</a> is available. It is
347
            similar to <a class="bodylink code" href="/functions/fn/doc">fn:doc()</a>, but takes a second
348
        argument which is a map supplying options for how the source document is to be parsed. The options allow control of
349
        schema and DTD validation, whitespace stripping, and use of accumulators. The function is <i>non-deterministic with respect
350
        to node-identity</i>: that is, if it is called twice with the same arguments, there are no guarantees about whether the same result
351
        is returned each time.</p>
352
        
353
        <p>The new extension function <a class="bodylink code"
354
            href="/functions/saxon/function-annotations">saxon:function-annotations()</a> is made available to obtain access to the annotations
355
            defined in a function declaration.</p>
356
        
357
        <p>The extension function <a class="bodylink code"
358
            href="/functions/saxon/timestamp">saxon:timestamp()</a> is added. It
359
            takes no arguments and returns the <code>xs:dateTimeStamp</code> 
360
        representing the instant at which the function is called. The optimizer makes some attempt to avoid rearranging calls
361
        to this function (for example by not lifting the call out of a loop) but order of execution is not guaranteed so there may
362
        still be surprises when the function is used to time program execution.</p>
363
        
364
        <p>The new extension function <a class="bodylink code" href="/functions/saxon/array-member">saxon:array-member()</a> takes
365
            a single argument, which evaluates to an arbitrary sequence, and it returns an external object of type <code
366
                java="com.saxonica.functions.extfn.ArrayMemberValue">ArrayMemberValue</code> wrapping this sequence. The
367
            significance of this external object is that it is specially recognized by operations that construct an array,
368
            indicating that the sequence contained by the <code>ArrayMemberValue</code>
369
            is to become a single member of the resulting array, rather than having each item treated independently.</p>
370
        
371
        <p>So, for example, the XPath expression <code>array{ saxon:array-member((1,2)), saxon:array-member((3,4)) }</code> creates
372
            the array <code>[(1,2), (3,4)]</code>. This is different from the result of <code>array{ (1,2), (3,4) }</code> which
373
        produces the array <code>[1, 2, 3, 4]</code>. This provides a pratical way of creating arrays containing nested sequences,
374
        especially useful where the number of members in the array is not known statically.</p>
375
        
376
        <p>A new function <a class="bodylink code" href="/functions/saxon/message-count">saxon:message-count($errCode)</a> is
377
            available. It returns the number of <a class="bodylink code" href="/xsl-elements/message">xsl:message</a>
378
        instructions that have been output with a given error code. If the argument is an empty sequence, it returns the total
379
        number of <code>xsl:message</code> instructions that have been output. A typical use case is to limit the number of
380
        messages that are output, or to terminate execution after reaching a particular threshold. 
381
        Because the <code>xsl:message</code> instruction has side-effects (including the side-effect
382
        of updating these counters) the results are not guaranteed to be predictable. This is particularly true when multi-threading.</p>
383
        
384
        <p>The implementation of <a class="bodylink code" href="/functions/saxon/stream">saxon:stream()</a> has undergone further
385
            changes, which bring it closer into line with
386
        the streamability rules for XSLT 3.0 streaming. When a filter expression is used as the argument, for example
387
        <code>saxon:stream(doc('a'xml')/b/c[PREDICATE])</code>, the predicate must now be motionless: this means for example that
388
        it cannot be positional, and it cannot access children or descendants or the string value of the node being tested. These restrictions
389
        can be circumvented by moving the predicate outside the call on <code>saxon:stream</code>, for example
390
            <code>saxon:stream(doc('a'xml')/b/c)[PREDICATE]</code>.</p>
391
        
392
        <h2>Extension Attributes</h2>
393
        
394
        <p>The attribute <code>saxon:time="yes"</code> on <a class="bodylink code" href="/xsl-elements/message">xsl:message</a>
395
            causes a timestamp to be added to the message output.</p>
396
        
397
        <p>The attribute <a class="bodylink code" href="/extensions/attributes/trace">saxon:trace="yes"</a> on
398
            <a class="bodylink code" href="/xsl-elements/accumulator">xsl:accumulator</a> causes tracing of all changes to the current
399
        value of the accumulator.</p>
400
        
401
        <p>The serialization property <code>saxon:single-quotes="yes|no"</code> controls whether the XML and HTML output methods use single
402
            or double quotes to delimit attributes (see <a class="bodylink"
403
                href="/extensions/output-extras/serialization-parameters">Serialization Parameters</a>). The default is to use
404
            double quotes, except in cases where character maps are involved; single
405
        quotes can be useful if the lexical XML/HTML is to be wrapped in a string literal delimited by double quotes, for example in JSON. This
406
        does not eliminate the need to escape double quotes (as <code>\"</code>) in such a context, but it means that fewer characters are
407
        affected.</p>
408
        
409
        <h2>Extension Instructions</h2>
410
        
411
        <p>The new instruction <a class="bodylink code" href="/extensions/instructions/array">&lt;saxon:array&gt;</a> has the same
412
            content model as <a class="bodylink code" href="/xsl-elements/sequence">&lt;xsl:sequence&gt;</a>, but
413
        builds an array rather than a sequence. The members of the array will all be singleton items, unless constructed using the
414
        <code>saxon:array-member</code> extension function or the <code>saxon:array-member</code> extension instruction (see above).</p>
415
        
416
        <p>The new instruction <a class="bodylink code"
417
            href="/extensions/instructions/array-member">&lt;saxon:array-member&gt;</a> has the same content model as
418
            <code>&lt;xsl:sequence&gt;</code>, but builds an external object of type <code
419
                java="com.saxonica.functions.extfn.ArrayMemberValue">ArrayMemberValue</code> wrapping the
420
            constructed sequence. The significance of this external object is that it is specially recognized by operations that
421
            construct an array, indicating that the sequence contained by the <code>ArrayMemberValue</code>
422
            is to become a single member of the resulting array, rather than having each item treated independently.</p>
423
            
424
        <p>An extension function <a class="bodylink code" href="/functions/saxon/array-member">saxon:array-member()</a> is also
425
            available.</p>
426
        
427
        <h2>Collection URIs</h2>
428
        
429
        <p>The standard collection URI resolver now accepts the parameter <code>match=<i>regex</i></code> as an alternative to <code>select=<i>glob</i></code>.
430
        The value is an XPath 3.1 regular expression. Characters that are not allowed in a URI (such as backslash and curly braces) must
431
        be escaped using the %HH convention; this is best achieved by processing the value through the <a class="bodylink code"
432
            href="/functions/fn/encode-for-uri">fn:encode-for-uri()</a> function.</p>
433
        
434
        <h2>XPath Syntax Extensions</h2>
435
        
436
        <p>Saxon implements a number of extensions to the XPath 3.1 grammar. These are enabled only if the configuration option
437
            <code
438
                java="net.sf.saxon.lib.FeatureKeys#ALLOW_SYNTAX_EXTENSIONS">FeatureKeys.ALLOW_SYNTAX_EXTENSIONS</code>
439
            is set, and they require Saxon-PE or higher.</p>
440
        
441
        <p><b>Simple inline functions</b>: an abbreviated syntax is available for defining simple inline functions. For example,
442
        the expression <code>fn{.+1}</code> represents a function that takes a single argument and returns the value of that
443
        argument plus one. A simple inline function takes a single argument with required type <code>item()</code>,
444
        and returns any sequence (type <code>item()*</code>). The function body is evaluated with a singleton focus based
445
        on the supplied argument value.</p>
446
        
447
        <p>Simple inline functions are particularly convenient when providing functions as arguments to higher-order functions,
448
            many of which accept a single item as their one argument.
449
            For example, to sort employees in order of salary, you can write <code>sort(//employee, fn{@salary})</code>.</p>
450

    
451
        <p>Simple inline functions can access externally-defined local variables in the usual way (that is, they have a closure).</p>
452
        
453
        <p>The expression <code>fn{EXPR}</code> is a syntactic shorthand for <code>function($x as item()) as item()* {$x!(EXPR)}</code>.</p>
454
        
455
        <!--<p><b>until</b> and <b>thru</b> operators. The expressions <code>A until C</code> and <code>A thru C</code> evaluate
456
            the expression <code>C</code> for every item in <code>A</code>, starting at the first item and continuing until the 
457
            first item is found for which the effective boolean value of <code>C</code> is true (call this <code>J</code>). 
458
            They return all items in <code>A</code> that precede <code>J</code>, plus <code>J</code> itself if the <code>thru</code>
459
            operator is used.
460
        </p>
461
        <p>The expression <code>C</code> is evaluated with the sequence <code>A</code> as its focus.</p>
462
        <p>For example, <code>1 to 100000 until (. mod 10 = 0)</code> returns (1 to 9), while <code>1 to 100000 thru (. mod 10 = 0)</code>
463
        returns (1 to 10).</p>
464
        <p>For a more realistic example, <code>* until self::h2</code> returns all child elements up to (but excluding) the first
465
        <code>h2</code> element.</p>
466
        <p>If no item in the sequence matches the condition, the entire sequence is returned.</p>-->
467
        
468
        <!--<p><b>for ... inArray</b> The clause <code>for $mem (as T)? (at P)? inArray $array</code> can be included in a FLWOR expression to iterate over the
469
        members of an array. Here <code>$array</code> can be any expression that evaluates to an array. The variable <code>$mem</code>
470
        is bound to each member of the array in turn (a member of an array can be any sequence).</p>-->
471
        
472
        <!--<p><b>andAlso</b> and <b>orElse</b> operators. These operators (often called short-circuit operators) 
473
            have the same effect as <code>and</code> and <code>or</code>,
474
        but they are guaranteed to evaluate the left-hand operand before the right-hand operand, and to avoid evaluating the
475
        right-hand operand when it is not needed. For example <code>if ($x castable as xs:date andAlso xs:date($x) > current-date())...</code>
476
        ensures that no failure occurs when <code>$x</code> is not a valid date. (The XPath specification offers no such guarantee
477
        for the <code>and</code> and <code>or</code> operators. Saxon will occasionally rearrange the order of evaluation, as permitted
478
        by the specification, if it thinks this will improve performance.)</p>-->
479
        
480
        <p><b>Type Aliases</b>. Wherever an <code>ItemType</code> is expected, instead of writing an explicit type like
481
        <code>map(xs:string, map(xs:integer, xs:string))</code>, it is possible to use a type alias, which is a QName prefixed with a tilde,
482
        for example <code>~inventory</code>. Type aliases can be declared in XSLT using the extension element
483
            <code>&lt;saxon:type-alias&gt;</code>;
484
            they are not currently available in XQuery. More details: see <a class="bodylink" href="/extensions/syntax-extensions/type-aliases">Type Aliases</a>.</p>
485
        
486
        <p><b>Union Types</b>. A union type is an extension to the syntax for an <code>ItemType</code>.
487
            An example is <code>union(xs:dateTime, xs:date, xs:time)</code>, which denotes a union type
488
            whose members are <code>xs:date</code>, <code>xs:time</code>, and <code>xs:dateTime</code>. 
489
            These types can conveniently be used in function signatures
490
            when writing a function that is designed to take arguments of more than one type. They can also be used in other
491
            places where an <code>ItemType</code> is required, for example in a <code>cast as</code> expression. 
492
            Requires Saxon-EE. The semantics are the same as for union types defined in a schema. For further details
493
            see <a class="bodylink" href="/extensions/syntax-extensions/union-types">Union Types</a></p>
494
        
495
        <p><b>Tuple Types</b>. A tuple type is an extension to the syntax for an <code>ItemType</code>. An example is
496
        <code>tuple(ssn: xs:string, emp: element(employee))</code>. A tuple type is essentially a way of defining a more
497
        precise type for maps. This example type will be satisfied by any map that has an entry whose key is "ssn" and whose
498
        value is a string, plus an entry whose key is "emp" and whose value is an <code>employee</code> element. More details: 
499
            see <a class="bodylink" href="/extensions/syntax-extensions/tuple-types">Tuple Types</a>.</p>
500
        
501
        <!--<p>saxon:split-before(sequence, function), saxon:split-after(sequence, function): these extension functions partition a sequence
502
            into an array of non-empty sequences, splitting the sequence immediately before|after any item for which the specified function
503
            returns true.</p> Similarly saxon:group-by(sequence, function), saxon:group-adjacent(sequence, function).-->
504
        
505
        
506

    
507
    </category>
508

    
509
    <category name="extensibility">
510
        
511
        <p>The abstract class <code java="net.sf.saxon.lib.ExtensionFunctionDefinition">ExtensionFunctionDefinition</code>, which
512
            is extended to implement
513
        user-defined integrated extension functions, now has a method <code>asFunction()</code> which
514
        returns the extension function as a function item (which can in turn be wrapped in an <code>XdmFunctionItem</code>).
515
        This allows extension functions written in Java to be used from Java as well as from XPath. For example,
516
        it allows a parameter to a query or stylesheet to be defined with type <code>function(*)</code>, and
517
        for a Java-written extension function to be supplied as the value of this parameter.</p>
518
        
519
        <p>When converting the result of a Java extension function to an XDM type, the s9api classes <code
520
            java="net.sf.saxon.s9api.XdmValue">XdmValue</code>
521
        and its subclasses (<code>XdmNode</code>, <code>XdmAtomicValue</code>, etc) are now recognized. This means that where
522
        explicit conversions are required, for example to a map or an array, the conversion methods on these classes can be used;
523
        for example, <code>XdmMap.makeMap()</code>, <code>XdmArray.makeArray()</code>.</p>
524
        
525
        <p><i>In Saxon 9.7, a <code>java.util.Map</code> passed as a stylesheet parameter was implicitly converted
526
        to an XDM map in Saxon-PE and Saxon-EE, but in Saxon-HE it was supplied as a wrapped external object. Saxon 9.8
527
        retains the Saxon-HE behaviour in all editions. To provide an XDM map, convert it explicitly using <code
528
            java="net.sf.saxon.s9api.XdmMap#makeMap">XdmMap.makeMap()</code></i>.</p>
529
        
530
       
531
       
532
    </category>
533

    
534

    
535

    
536

    
537
    <category name="internal">
538
        
539
        <p>The mechanism for binding system functions has been reorganized and made more modular. One effect of this is that it is now possible to
540
        have different signatures for the same function depending on the configuration; for example the signature for
541
            <a class="bodylink code" href="/functions/fn/string-join">string-join()</a>
542
        is different between XPath 3.0 and XPath 3.1. Another effect is that the same mechanism can now be used for namespaces other than the
543
        standard function namespace, and this has been exploited to re-implement other function libraries including the math functions, the
544
        exslt-common functions, and the Saxon vendor extensions, which were previously implemented in the same way as user-supplied extension functions.
545
        This makes the implementation more concise and allows greater control over aspects such as streamability.</p>
546
        
547
        
548
        
549
        
550
       
551
    </category>
552

    
553

    
554
    <category name="xsd10">
555
        
556
        <p>The default XSD version has changed to 1.1. That is, XSD 1.1 features are now enabled by default; it is still possible to
557
        request processing with XSD 1.1 features disabled by setting the requested XSD version to 1.0.</p>
558
        
559
        <p>The performance of validation against user-defined simple types has been improved by using bytecode generation to generate
560
        a validation method for each simple type. This bypasses a great deal of "control logic" working out at validation time what facets exist for
561
        each type, and in some cases avoids repetitive conversions.</p>
562
        
563
        
564

    
565
    </category>
566
    
567
    <category name="xsd11">
568
        
569
        <p>The default XSD version has changed to 1.1. That is, XSD 1.1 features are now enabled by default; it is still possible to
570
            request processing with XSD 1.1 features disabled by setting the requested XSD version to 1.0.</p>
571
    </category>
572

    
573
    <category name="dotnet">
574

    
575
        <p>It is now possible to define a custom <code java="Saxon.Api.WhitespacePolicy">WhitespacePolicy</code> by supplying a
576
            callback predicate which indicates whether
577
        whitespace for a particular element name is to be stripped or preserved. This provides XQuery users with a mechanism comparable to
578
        XSLT's <code>xsl:strip-space</code> and <code>xsl:preserve-space</code>, and allows fine-grained control of whitespace stripping
579
        to be taken out of the control of the transformation.</p>
580

    
581
        <p>The <code java="Saxon.Api.Serializer">Serializer</code> class has two new convenience methods, allowing serialization
582
            of an <code>XdmNode</code> to an arbitrary <code>Destination</code>,
583
            or more simply to a string in .NET. These methods are equivalent to the Java versions.</p>
584

    
585

    
586
        <p>New classes <code>XdmMap</code> and <code>XdmArray</code> have been added as subclasses of <code>XdmFunctionItem</code>,
587
                making it easier to pass maps and arrays as parameters to queries or stylesheets.  The <code>XdmMap</code> class implements
588
                the constructor with the argument <code>System.Collections.Generic.Dictionary&lt;XdmAtomicValue, XdmValue></code>, allowing it to be used directly in
589
            contexts where a .NET Dictionary
590
                is expected (it is immutable, however).</p>
591
        <p>The <code>XdmArray</code> class implements the constructor with the argument <code>System.Collections.Generic.List&lt;XdmValue></code>,
592
        allowing it to be used directly in context where a .NET List is expected.</p>
593
        <p>The <code>XdmValue</code> class now has a new convenience method to make an XdmValue: <code>MakeValue(object)</code></p>
594

    
595
        <p>The <code>XdmAtomicValue</code> class now has a new convenience static method to make an XDM Atomic Value, namely: <code>MakeAtomicValue(object)</code>.
596
             The following types are accepted: AtomicValue, boolean, string, int, long, short, char, byte, decimal, Uri and QName.
597
        We now have the method <code>Equal(object)</code> to compare two atomic values for equality.
598
            We now have the method <code>GetHashCode()</code> to get a hash code to support the equality of comparison</p>
599
    </category>
600

    
601

    
602
    <category name="s9api">
603
        
604
        <p>With the <code java="net.sf.saxon.s9api.DocumentBuilder">DocumentBuilder</code> class, when DTD or schema validation is
605
            requested, the <code java="net.sf.saxon.s9api.WhitespaceStrippingPolicy">WhitespaceStrippingPolicy</code> setting
606
        was previously ignored (although the documentation didn't make this clear): whatever the setting, whitespace nodes were stripped if and
607
        only if they appeared in elements with element-only content. This has changed so that any explicit setting other than
608
            <code>WhitespaceStrippingPolicy.IGNORABLE</code> results in an exception reporting the error.</p>
609
        
610
        <p>It is now possible to define a custom <code>WhitespaceStrippingPolicy</code> by supplying a callback predicate which indicates whether
611
        whitespace for a particular element name is to be stripped or preserved. This provides XQuery users with a mechanism comparable to
612
        XSLT's <code>xsl:strip-space</code> and <code>xsl:preserve-space</code>, and allows fine-grained control of whitespace stripping
613
        to be taken out of the control of the transformation.</p>
614
        
615
        <p>The constructors for the <code java="net.sf.saxon.s9api.Serializer">Serializer</code> class (deprecated since 9.6) have been removed; the factory methods on
616
            <code java="net.sf.saxon.s9api.Processor">Processor</code> must now be used instead. This change ensures that the <code>Serializer</code> is always bound to a specific
617
        <code>Processor</code>.</p>
618
        
619
        <p>New classes <code java="net.sf.saxon.s9api.XdmMap">XdmMap</code> and <code
620
            java="net.sf.saxon.s9api.XdmArray">XdmArray</code> have been added as subclasses of <code
621
                java="net.sf.saxon.s9api.XdmFunctionItem">XdmFunctionItem</code>,
622
        making it easier to pass maps and arrays as parameters to queries or stylesheets. Maps and arrays are also now supported
623
        in the s9api <code java="net.sf.saxon.s9api.ItemType">ItemType</code> and <code
624
            java="net.sf.saxon.s9api.ItemTypeFactory">ItemTypeFactory</code> classes. The <code>XdmMap</code> class implements
625
        the interface <code>java.util.Map&lt;XdmAtomicValue, XdmValue></code>, allowing it to be used directly in contexts where a Java map
626
        is expected (it is immutable, however).</p>
627
        
628
        <p>The class <code java="net.sf.saxon.s9api.XdmAtomicValue">XdmAtomicValue</code> now has <code>equals()</code> and
629
            <code>hashCode()</code> methods that reflect the semantics
630
            of the <code>op:is-same-key()</code> relation which is used to compare keys in maps. (Without this, the <code>XdmItem.asMap()</code>
631
            method was not very useful).</p>
632
        
633
        <p>Static methods have been added to <code>XdmValue</code>, <code>XdmAtomicValue</code>, <code>XdmMap</code>, and <code>XdmArray</code>,
634
        to allow conversion from ordinary Java values. For example, <code>XdmArray.makeArray()</code> will construct an array of <code>xs:int</code>
635
        values from a Java <code>int[]</code> array.</p>
636
        
637
        <p>A static method <code
638
            java="net.sf.saxon.s9api.XdmFunctionItem#getSystemFunction">XdmFunctionItem.getSystemFunction()</code> allows a
639
            function item representing a built-in function
640
        to be obtained. This can then be used for direct calls on system functions from the Java application without the inconvenience of 
641
        parsing an XPath expression to represent the function call.</p>
642
        
643
        <p>The method <code java="net.sf.saxon.s9api.XdmFunctionItem#call">XdmFunctionItem.call()</code> has been enhanced to
644
            apply the function conversion rules to the supplied
645
        arguments, and to return a clean error message (rather than a <code>ClassCastException</code>) if the supplied arguments are of the wrong type.</p>
646
        
647
        <p>The method <code>Xslt30Transformer.setMessageListener()</code> is
648
            supplemented with a variant that accepts a <code java="net.sf.saxon.s9api.MessageListener2">MessageListener2</code>
649
        as its parameter; the <code>MessageListener2</code> interface allows the <code>xsl:message</code> error code to be reported along with the message
650
        itself.</p>
651
        
652
        
653
    </category>
654
        
655

    
656

    
657
    <category name="localization">
658
        
659
        <p>UCA collation URIs (as defined in both the XSLT 3.0 and Functions and Operators 3.1 specifications) are now recognized
660
        in Saxon-HE as well as -PE and -EE. In Saxon-HE, they are supported only if the <code>fallback</code> option takes
661
        its default value of <code>yes</code>, and all options other than <code>lang</code>, <code>strength</code>, and
662
        <code>normalization</code> are ignored. The implementation uses the built in Java collation support, rather than (as in Saxon-PE and -EE)
663
        the separate ICU library. The set of locales that are recognized in the <code>lang</code> parameter depends on the version
664
        of Java that is installed.</p>
665
        
666
        <p>The ICU library is updated from version 57.1 to version 59.1. This brings Unicode 9.0 support.</p>
667
       
668
    </category>
669

    
670
    <category name="optimization">
671
        
672
        <p>Saxon-EE 9.8 introduces hot-spot bytecode generation. In the past, bytecode generation was done unconditionally, unless disabled
673
        entirely. Since the costs of bytecode generation can exceed the benefits unless the code is executed frequently enough to amortize the cost,
674
        this meant that the faster run time was sometimes insufficient to compensate for the increase in compile time. In Saxon-EE 9.8, by default, sections
675
        of XSLT or XQuery code are initially interpreted, with bytecode being generated only after the code has been executed a set number of times.
676
        By default the threshold is 300 executions; this can be changed by setting the configuration property <code>FeatureKeys.GENERATE_BYTE_CODE</code>
677
        to an integer value. (Boolean values for this property are still supported, with "true" setting a threshold of 0, and "false" setting a threshold
678
        of infinity.)</p>
679
        
680
        <p>In addition, bytecode generation is now more selective. In the past, when a construct was used for which bytecode generation
681
        was not implemented, the entire function or template was interpreted. Now, only the construct in question (and its operands,
682
        recursively) is interpreted. This means we can focus effort on generating bytecode for those constructs where it genuinely
683
        adds value; there is also a memory saving because generating bytecode for everything can consume a lot of memory (which 
684
        can particularly be a problem because memory used for loaded classes is not a high priority for garbage collection).</p>
685
        
686
        <p>In XSLT, Saxon-EE 9.8 further reduces compile time by using just-in-time compilation of template rules. During stylesheet static analysis,
687
        the match patterns of all template rules in a mode are analyzed in the usual way and are used to build a data structure supporting fast
688
        determination of the best-matching template rule for any node. The actual body of the template rule, however, is not compiled until the first
689
        time a particular rule fires. This can substantially improve stylesheet compilation time for very large stylesheets (examples being the DocBook
690
        and DITA stylesheets) which often contain thousands of template rules that are never used in a particular transformation run, because source
691
        documents typically only use a small part of the DocBook or DITA vocabulary.</p>
692
        
693
        <p>A consequence of this change is that static errors in the stylesheet may go undetected if the template rule in question is not exercised.
694
        During stylesheet development, to ensure that all static errors are detected, users are therefore advised to disable this option. This can be done on
695
        the command line using the option <code>-opt:-j</code>, or by setting the configuration property <code>FeatureKeys.OPTIMIZATION_LEVEL</code>
696
        to "-j".</p>
697
        
698
        <p>Just-in-time compilation is automatically disabled if a stylesheet is compiled for export using the <code>-export</code> option.</p>
699
        
700
        <p>A new optimization is introduced in Saxon-EE: elimination of common subexpressions. Where the same expression appears more than once within a function
701
        or template, and the evaluation context is the same, and the expression does not create new nodes, and where certain other conditions are met,
702
        a local variable is now introduced and bound to the value of the expression, and the multiple occurrences of the expression are replaced with
703
        references to the variable. (Note that stylesheet authors should not rely on this optimization occurring, since not all cases will be detected.)</p>
704
        
705
        <p>Saxon-EE now generates bytecode for validation of input strings against user-defined simple types. This is most useful when there is a complex
706
        type hierarchy and many facets. Validation of simple types is often the main bottleneck during schema validation.</p>
707
        
708
        <p>The optimizer trace produced with the <code>-explain</code> option on the command line, or with <code>FeatureKeys.TRACE_OPTIMIZER_DECISIONS</code>
709
        is now more compact, and also covers a wider range of optimizations.</p>
710
        
711
        <p>The code for loop-lifting and for extraction of global variables has been rewritten, making it more efficient.
712
        There may be some differences in the detailed circumstances in which expressions are extracted from loops.</p>
713
        
714
        <p>The experimental code in Saxon 9.7 for optimizing searching of large sets of XSLT template rules has been rewritten and productized.
715
            The new code is designed to handle sets of rules making extensive use of similar predicates, for example
716
            <code>match="*[XXX = 'constant']</code> where XXX is the same expression in every rule, and 'constant' is a different constant
717
            in every rule. The main benefit comes from only evaluating the expression XXX once for each rule in the set; in addition many
718
            matches can be quickly eliminated by comparing integer hash codes rather than the full strings.</p>
719
        
720
        <p>The optimization pays particular attention to the kind of pattern found throughout the DITA-OT stylesheets, which make extensive use
721
            of predicates of the form <code>match="*[contains(@class, ' topic/abc ']/*[contains(@class, ' topic/def ')]</code>. These are
722
            processed using the following logic:</p>
723
        
724
        <ol>
725
            <li>First, where several rules share the same parent pattern (here <code>*[contains(@class, ' topic/abc ']</code>), this
726
            parent pattern is only evaluated once, and if it fails to match, all rules using this qualifier are automatically eliminated
727
            from the search.</li>
728
            <li>The particular call on <code>contains()</code> with a second argument comprising a token wrapped between space characters
729
            is recognized as one that can be efficiently evaluated by tokenizing the value of the <code>@class</code> attribute on whitespace
730
            boundaries. In effect, it is evaluated as <code>tokenize(@class) = 'topic/def'</code>; but with the extra refinements that the
731
            tokenization of the <code>@class</code> attribute is only done once for all rules in the set, and further that this set of tokens is 
732
                converted to a set of integer hash codes
733
            which can then be compared with the integer hash code computed at compile time for the search target <code>topic/def</code>.</li>
734
        </ol>
735
        
736
        <p>In a stylesheet export file, functions that are not explicitly referenced are no longer exported unless (a) they have non-private
737
        visibility, or (b) the stylesheet package contains an <code>xsl:evaluate</code> instruction or a call on <code>fn:function-lookup()</code>.
738
        This reduces the size of export files for stylesheets that export large function libraries (such as the FunctX library) when they only
739
        want to use one or two functions from that library.</p>
740
        
741
        <p>Type-checking on maps has been redesigned. Static type inferencing has been improved, so there should be fewer cases where
742
        run-time type checking is needed. Operations that update maps with new entries keep track of the primitive type of the keys and the
743
        values, so that run-time type checks involving only primitive types should be very fast. Type checking is also fast if the keys and values
744
        are homogenous, that is, if all keys have the same type, and all items in all values have the same type. More complex type checks 
745
        can take time proportional to the number of entries, so such types should be used with care.</p>
746
        
747
        <p>Saxon-EE now optimizes the <code>xsl:number</code> instruction with <code>level="any"</code> by rewriting the instruction
748
            (where possible) to use an internal accumulator. The assumption is that if one node in the document is being numbered, it is very
749
            likely that many other nodes in the document will be numbered, and that it is therefore worth calculating all the numbers in 
750
            a single pass. The optimization is only possible when there is a <code>count</code> pattern (or where a <code>count</code>
751
            pattern can be inferred), and where certain other conditions are satisfied: neither the <code>count</code> nor <code>from</code>
752
            patterns may contain local variable references or references to the <code>current()</code> function; and neither must be
753
            capable of matching attribute or namespace nodes (because these are not visited by accumulators).</p>
754
        
755
        
756
        
757
    </category>
758

    
759

    
760
</release>
(4-4/6)