<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="changes" page="intro92" subpage="install92"/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Installation and Licensing</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title"
            content="Saxonica: XSLT and XQuery Processing: Installation and Licensing"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>Installation and Licensing</h1>
      <p class="subhead">JDK dependency</p>
      <p>Saxon on the Java platform now requires J2SE 5 (often called JDK 1.5) or later. It no longer works with
JDK 1.4.</p>
      <p class="subhead">Repackaging</p>
      <p>Saxon is now available in three editions: Home (HE), Professional (PE), and Enterprise (EE). The Home Edition is open-source,
 available free of charge, and runs without a license file. The Professional and Enterprise editions both require a license
 key obtainable from Saxonica.
</p>
      <p>The Saxon-SA product has been renamed Saxon-EE (for "Enterprise Edition") to reflect the fact that it contains many added-value
features beyond schema-awareness: for example, streaming, XQuery Updates, compilation of queries to Java code, 
separate compilation of query libraries, and an advanced query optimizer.</p>
      <p>The JAR and DLL files are renamed accordingly (for example saxon9ee.jar, saxon9ee.dll).</p>
      <p>The <code>Configuration</code> class for Saxon-EE (previously <code>com.saxonica.validate.SchemaAwareConfiguration</code>)
is now renamed <code>com.saxonica.config.EnterpriseConfiguration</code>. This change reflects that fact that use of this Configuration
enables all features that are exclusive to Saxon-EE, of which schema-awareness is only one. The Configuration class for Saxon-PE
is named <code>com.saxonica.config.ProfessionalConfiguration</code>, while that for Saxon-HE is simply 
 <code>net.sf.saxon.Configuration</code>.</p>
      <p>The JAXP factory classes for Saxon-EE (previously <code>com.saxonica.SchemaAwareTransformerFactory</code> and
<code>SchemaAwareXPathFactory</code>) are renamed <code>com.saxonica.config.EnterpriseTransformerFactory</code> and
<code>com.saxonica.config.EnterpriseXPathFactory</code>.</p>
      <p>Similarly, Saxon-PE (professional edition) offers <code>com.saxonica.config.ProfessionalTransformerFactory</code> and
  <code>com.saxonica.config.ProfessionalXPathFactory</code>.</p>
      <p>Some features that were previously available in the open-source product Saxon-B are not included in the Saxon-HE 
 (home edition) product
build. These features are all optional extras, in the sense that they are not required for conformance
to the W3C or Java API standards. The relevant features are:</p>
      <ul>
         <li content="para">
            <p>The traditional mechanism for binding extension functions by reflexion (searching the classpath for matching
 names) is now available only in Saxon-PE and Saxon-EE. In Saxon-HE, the only way to define extension functions
 is the new mechanism of "integrated extension functions", which need to be explicitly registered with the
 Configuration.</p>
         </li>
         <li content="para">
            <p>All extension functions in the Saxon namespace <code>http://saxon.sf.net/</code> now require at least Saxon-PE.</p>
         </li>
         <li content="para">
            <p>All EXSLT extension functions now require at least Saxon-PE.</p>
         </li>
         <li content="para">
            <p>The XSLT extension instructions <code>saxon:assign</code>, <code>saxon:call-template</code>,
 <code>saxon:doctype</code>, <code>saxon:entity-ref</code>, <code>saxon:import-query</code>,
 <code>saxon:script</code>, and <code>saxon:while</code> now require Saxon-PE.</p>
         </li>
         <li content="para">
            <p>The SQL extension: that is, the extension instructions <code>sql:connect</code>, etc, is not available in Saxon-HE. The code
 for this extension remains available as an open-source plug-in for use with Saxon-PE or Saxon-EE.</p>
         </li>
         <li content="para">
            <p>External object model support for JDOM, DOM4J, and XOM is not available for Saxon-HE "out of the box".
 However, the source code for these extensions remains available in open-source form, and can be used by compiling it and
 registering it with the Configuration.</p>
         </li>
         <li content="para">
            <p>Memo functions, previously available in Saxon-B, now require Saxon-PE or Saxon-EE. Any request in a stylesheet or query to 
 create a memo function is ignored under Saxon-HE with a warning.</p>
         </li>
         <li content="para">
            <p>The ability to "compile" stylesheets (that is, to create a Java serialization of the internal representation)
 is now available only in Saxon-EE. The command to achieve this is renamed <code>com.saxonica.CompileStylesheet</code>.
 Such stylesheets can be executed under Saxon-HE, but because they have always required a dedicated <code>Configuration</code>,
 this is now packaged for use only from the command line (if you need to run it from a different application, you can copy the
 relevant code from the <code>net.sf.saxon.Transform</code> source, and you must take responsibility for ensuring that the
 application runs in its own <code>Configuration</code>.)</p>
         </li>
         <li content="para">
            <p>Localization support for a number of languages other than English in <code>xsl:number</code> and in the
 <code>format-dateTime()</code> family of functions is provided by means of modules in package 
  <code>net.sf.saxon.option.local</code>. These modules are included in the JAR files for Saxon-PE and Saxon-EE; 
 if required for Saxon-HE they can be compiled from source code. In all cases they are no longer picked up automatically
 by virtue of class naming conventions, instead they must be explicitly registered with the Configuration either by using
 the method <code>setLocalizationClass()</code> or, in Saxon-PE and Saxon-EE, via the configuration file.</p>
         </li>
      </ul>
      <p>Some features that were previously available only in Saxon-SA are now available in Saxon-PE (without open source code). 
These include:</p>
      <ul>
         <li content="para">
            <p>The PTree persistent XML tree format</p>
         </li>
         <li content="para">
            <p>A number of extension functions: saxon:analyze-string(), saxon:call(), saxon:find(), saxon:index(), 
  saxon:for-each-group(), saxon:format-dateTime(), saxon:format-number(), saxon:function(),
  saxon:generate-id(), saxon:try()</p>
         </li>
         <li content="para">
            <p>Support for a subset of the new facilities in XQuery 1.1 (grouping, 
  format-number(), format-date(), etc)</p>
         </li>
      </ul>
      <p>Schema-awareness is now a property of a compiled query, stylesheet, or XPath expression. By default, these executables
are schema-aware if they contain an import schema declaration in the source code, or if a schema was imported
programmatically into the static context for the compilation. If the executable is not schema-aware, then all the data
supplied at run-time must be untyped. The reason for this is that there is a considerable performance penalty if it is not
known statically whether data will be typed or untyped; therefore, code that is not explicitly declared to be schema-aware
is now compiled to handle untyped data only. (This allows the type annotations <code>xs:untyped</code>, <code>xs:anyType</code>,
and <code>xs:untypedAtomic</code>. Of these, <code>xs:anyType</code> will appear only in nodes constructed from within a
query, and only when construction mode is "preserve".)</p>
      <p>For XSLT a transformation can be set to be schema-aware, even if it does not import a schema, by setting the Configuration
property <code>FeatureKeys.XSLT_SCHEMA_AWARE</code> to true. For XQuery, the same effect can be achieved by setting the Configuration
property <code>FeatureKeys.XQUERY_SCHEMA_AWARE</code>.</p>
      <p>The command-line interfaces <code>Transform</code> and <code>Query</code> will now load an enterprise configuration if they
can (that is, if Saxon-EE and a valid license file can be located). The <code>-sa</code> option is now needed only to enable
schema-awareness in a transformation or query that does not import a schema. This might be needed, for example, if the
transformation or query uses untyped input but validates its output. The option is no longer needed to enable other
Saxon-EE features such as advanced optimization or streaming.</p>
      <p class="subhead">Licensing changes</p>
      <p><i>The notes below are non-normative: for definitive statements, you need to read the license text.</i></p>
      <p>Saxon-PE and Saxon-EE (professional and enterprise editions) are available under commercial license terms. 
 These impose the usual commercial restrictions,
for example redistribution of the software is allowed only under an explicit agreement.</p>
      <p>The open source product, Saxon-HE, is available under the same conditions as its predecessor, Saxon-B: that is,
the Mozilla Public License.</p>
      <p>The effect of this is that there are very few restrictions on applications built using Saxon-HE:
the JAR file can be distributed with the application, and the application can be issued under any licensing terms you choose,
whether commercial or open source. The only
restriction you need to watch out for is that there is a requirement to distribute the notices contained 
in the <code>notices</code> directory whenever you distribute the JAR file itself. Some popular software distribution
mechanisms such as <code>maven</code> are currently unable to satisfy this obligation.</p>
      <p class="subhead">License keys</p>
      <p>Saxon-EE and Saxon-PE on .NET now uses the same license key files as Saxon on Java. For the time being, 
Saxon-EE on .NET will also work
with previously issued .NET license keys, but all new license keys issued will be in cross-platform format.</p>
      <p>For Saxon-EE and Saxon-PE on Java, it is no longer necessary for the directory containing the license key file to be on the classpath.
Instead, the license file <code>saxon-license.lic</code> can be installed in the directory containing the <code>saxon9ee.jar</code>
 or <code>saxon9pe.jar</code>
file, where Saxon will find it automatically. Saxon now looks first in this location, and then on the classpath.</p>
      <p>Since the license key directory no longer needs to be on the classpath, the class <code>net.sf.saxon.Transform</code> is now the
registered entry point for all three JAR files: saxon9he.jar, saxon9pe.jar, and saxon9ee.jar, making it possible to run all three products
using the <code>-jar</code> option on the command line.</p>
      <p>There has been some abuse of evaluation licenses, notably in developing countries. Two measures have been introduced to discourage the use of evaluation
licenses for production work:</p>
      <ul>
         <li content="para">
            <p>Saxon now disables the use of evaluation licenses for a short period each day (typically five minutes, but random). These events are designed to
be sufficiently rare that genuine evaluation projects are not impacted, but sufficiently frequent to cause a nuisance when
attempting to run a production workload using an evaluation license.</p>
         </li>
         <li content="para">
            <p>Occasionally and at random, in about 1% of runs, when running with an evaluation license Saxon will insert asterisks into the output when
   serializing.</p>
         </li>
      </ul>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="s9api92.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>