You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


<?xml version="1.0" encoding="utf-8"?>
<article id="starting" title="Getting started">
   <h1>Getting started</h1>
        
        <p>This section of the documentation describes how to get hold of Saxon-CE, how to install
        it, and how to get started writing applications that take advantage of it.</p>
        <p>There is also information for people who want to get the source code and rebuild the
        product from source, though this is a complex process and the average user has no need to
        understand this.</p>
    <section id="installing" title="Installing the Software">
      <h1>Installing the Software</h1>
        
        <p>Saxon-CE consists entirely of Javascript code (highly compressed and obfuscated)
           which is downloaded from your web site to run in the user's browser. There is no
           server-side component. The Javascript modules can therefore simply be placed alongside
           any necessary XML and HTML files in a static area of your web site. There are no dependencies
           on any server-side software beyond a basic web server.</p>
        <p>The software is issued as two directories <code>Saxonce</code> and
                <code>SaxonceDebug</code>, each containing a similar set of files, the first
            optimized for production and the second for development. (The files are generated by the
            GWT compiler from Java source code, with diagnostic code 'compiled out' for the files in
            the production directory). The code all runs client-side: there are no dependencies on
            the web server environment other than the ability to serve static content.</p>
        <p>One of the included files (in each directory), <code>Saxonce.nocache.js</code>, is the
            entry point, and is referenced from a <code>script</code> element in user-written HTML
            pages.</p>
        <p>The other files have cryptic hexadecimal names. There are in fact five such files, each
            containing almost the same code, but each tailored for a different browser. The master
            code <code>Saxonce.nocache.js</code> will load whichever of these modules is appropriate
            to the browser in use.</p>
        
        <p>Also included in each directory are two data files, <code>normalizationData.xml</code>
            and <code>unicodeBlocks.xml</code>. These contain information used by the XPath
                <code>normalize-unicode()</code> function and regular expression functions
            respectively; they're read from the server only if such a function is actually
            called.</p>
        <p>These directories should simply be copied into an appropriate
            location in the web server's filestore layout, where they can be referenced from HTML
            pages in the same way as other JavaScript components.</p>
    </section>
   <section id="running" title="Running Saxon">
      <h1>Running Saxon</h1>
        
        <ul>
            <li>
                <p>
                    <a class="bodylink" href="/starting/running/pi-sample">XML-Stylesheet
                        Processing Instruction</a>
                </p>
            </li>
            <li>
                <p>
                    <a class="bodylink" href="/starting/running/xsltscript">XSLT 2.0 Script
                        Element</a>
                </p>
            </li>
            <li>
                <p>
                    <a class="bodylink" href="/api/command">Using the Command object</a>
                </p>
            </li>
            <li>
                <p>
                    <a class="bodylink" href="/api/xslt20processor">Using XSLT20Processor</a>
                </p>
            </li>
        </ul>
        <p>XSLT 2.0 transforms can be started from Saxon-CE in various ways to suit your
            requirement. This section provides an overview of the different transform methods along
            with links to more detailed documentation.</p>
        <h2 class="subtitle">XML-Stylesheet Processing-Instruction</h2>
        <p>The first method employs a standard <code>&lt;?xml-stylesheet?&gt;</code>
            processing-instruction in the prolog of an XML document, as shown below:</p>
        <samp><![CDATA[
            <?xml-stylesheet type="text/xsl" href="sample.boot.xsl"?>
<dt:data-set xmlns:dt="urn:system.logging.data.xml">
  <dt:rows name="test-data">
  ...
</dt:data-set>]]></samp>
        <p>This provides the easiest upgrade from existing XSLT 1.0 applications. Because the
            processing instruction is read by the browser, not by Saxon, it can't load the XSLT 2.0
            stylesheet directly. Instead, the <code>href</code> pseudo-attribute references a <a class="bodylink" href="/starting/running/pi-sample">small XSLT 1.0 boot
                stylesheet</a>, which then 'bootstraps' the Saxon processor. The boot stylesheet
            is not executed by Saxon-CE, but by the browser's built-in XSLT 1.0 processor. It
            uses JavaScript literal object properties, such as <code>stylesheet:</code> to set the
            URL of the actual XSLT 2.0 stylesheet to run (a sample is included in the
                <code>samples</code> directory in the Saxon-CE download).</p>
        <section id="pi-sample" title="The Processing-Instruction's Boot Stylesheet">
         <h1>The Processing-Instruction's Boot Stylesheet</h1>
            
            <p>The Processing Instruction:</p>
            <samp><![CDATA[
                <?xml-stylesheet type="text/xsl" href="sample.boot.xsl"?>]]></samp>
            <p>This XSLT 1.0 stylesheet is run from a <code>&lt;?xml-stylesheet?&gt;</code>
                processing-instruction. When the skeleton HTML page loads in the browser, Saxon-CE
                is run (using JavaScript), this then executes an XSLT 2.0 transform on the 'host'
                XML document using a stylesheet (sample.xsl) set with the <code>stylesheet</code>
                property.</p>
            <samp><![CDATA[
                
<xsl:transform
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     version="1.0">
     
    <xsl:output method="html" indent="no"/>
    <xsl:template match="/"> 
        <html>
            <head>
                <meta http-equiv="Content-Type" content="text/html" />
                <script type="text/javascript" language="javascript"
                        src="../Saxonce/Saxonce.nocache.js"/>
                        
                <script>
                    var onSaxonLoad = function() {
                        Saxon.run( {
                             source:     location.href,
                             logLevel:   "SEVERE",
                             stylesheet: "sample.xsl"
                        });
                    }
                </script>
                
            </head>
            <!-- these elements are required also -->
            <body><p></p></body>
        </html>    
    </xsl:template>
    
</xsl:transform>
]]></samp>
        </section>
        <h2 class="subtitle">Loading Saxon-CE</h2>
        <p>The XML processing-instruction described above exploits a 'boot' stylesheet to load
            Saxon-CE. When initiating an XSLT transform using the alternative methods described
            below, you first need to load Saxon-CE using a standard JavaScript <code>script</code>
            element within the HTML <code>head</code> or <code>body</code> elements:</p>
        <samp><![CDATA[
            <script type="text/javascript" language="javascript" src="../Saxonce/Saxonce.nocache.js"></script>
        ]]></samp>
        <p>
            <strong>
                <i>Note on using JavaScript to run XSLT on page-load</i>
            </strong>
        </p>
        <p>The Saxon-CE module is loaded using deferred loading. When executing a transform on
            page-load using JavaScript it's important that JavaScript API calls are initiated from
            within a user-declared <code>onSaxonLoad</code> function. This is to ensure that
            Saxon-CE loads first:</p>
        <samp><![CDATA[var onSaxonLoad = function() { Saxon.requestXML('data.xml'); ... };]]></samp>
        <h2 class="subtitle">Using an XSLT 2.0 Script Element</h2>
        <p>You can use the <a class="bodylink" href="/starting/running/xsltscript">XSLT Script
                Element</a> when you only need to execute a single transform when the HTML page
            loads, and no XSLT parameters or configuration settings are required.</p>
        <samp><![CDATA[<script type="application/xslt+xml" language="xslt2.0" src="books.xsl" data-source="books.xml"></script>]]></samp>
        <section id="xsltscript" title="Script Element">
         <h1>Script Element</h1>
            
            <p>Using a Script Element is the the most direct way of executing an XSLT transform from
                Saxon-CE. You need two <code>script</code> elements, one for the Saxon-CE code, and
                one for the XSLT stylesheet:</p>
            
            <samp><![CDATA[
<script type="text/javascript" language="javascript" src="../Saxonce/Saxonce.nocache.js"></script>

<script type="application/xslt+xml" language="xslt2.0" src="books.xsl" data-source="books.xml"></script>]]></samp>
            <p>The first <code>script</code> element is a reference to the Saxon-CE code, located by
                means of a relative URI in the normal way. The module
                    <code>Saxonce.nocache.js</code> is a small stub module located within the
                Saxonce directory, this in turn brings in one of a number of larger modules
                containing the compiled XSLT engine, in slightly different forms depending on which
                browser is in use.</p>
            <p>
                <i>Note: The relative URI to the Saxon-CE code may reference either the debug or
                    production directories that are shipped with Saxon-CE, depending on the
                    requirement. See <a class="bodylink" href="/starting/installing">Installing the
                        Software</a> for details.</i>
            </p>
            <p>The second <code>script</code> element typically contains references to the source
                document and stylesheet. Again these are relative URIs.</p>
            <p>The attributes recognized on this element are:</p>
            <table>
                <tr>
                    <td>
                        <p>
                            <strong>Attribute</strong>
                        </p>
                    </td>
                    <td>
                        <p>
                            <strong>Meaning</strong>
                        </p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>type</p>
                    </td>
                    <td>
                        <p>Should always be <code>application/xslt+xml</code></p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>language</p>
                    </td>
                    <td>
                        <p>Should always be <code>xslt2.0</code></p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>src</p>
                    </td>
                    <td>
                        <p>Mandatory. Relative URI of the XSLT stylesheet</p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>data-source</p>
                    </td>
                    <td>
                        <p>Optional. Relative URI of the initial source document. If absent, the
                            attribute <code>data-initial-template</code> must be present.</p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>data-initial-template</p>
                    </td>
                    <td>
                        <p>Name of the named template in the stylesheet at which execution is to
                            commence. If this is namespace-qualified, use Clark notation
                                <code>{uri}local</code>.</p>
                    </td>
                </tr>
                <tr>
                    <td>
                        <p>data-initial-mode</p>
                    </td>
                    <td>
                        <p>Name of the mode in the stylesheet at which execution is to commence. If
                            this is namespace-qualified, use Clark notation
                            <code>{uri}local</code>.</p>
                    </td>
                </tr>
            </table>
            <p>Assuming that <code>data-source</code> is supplied, execution proceeds as follows.
                When the page is loaded, the Saxon stub will be executed, the source document will
                be fetched, the stylesheet will be compiled, and the stylesheet will be invoked with
                the source document as its principal input (initial context node). So the
                &lt;xsl:template match="/"&gt; template will be invoked in the usual way.</p>
            <p>When using XSLT 1.0 in the browser, it is common to generate a complete HTML page as
                output from the transformation. With XSLT 2.0, a more effective technique is to
                write multiple fragments of HTML, using them to populate named portions of the HTML
                page. So the initial HTML page will generally contain a skeletal structure of
                elements such as <code>div</code> element, each with an <code>id</code> attribute,
                waiting to be populated by the stylesheet.</p>
        </section>
        <h2 class="subtitle">Running XSLT from declarative JavaScript</h2>
        <p>This utilizes a single call to the <code>run</code> function in the Saxon namespace. This
            takes as its single argument a <a class="bodylink" href="/api/command">Command object</a>
            containing a description of the transformation to be executed.</p>
        <p>Use this when a bit more flexibility is required, such as the need to set XSLT parameters
            or dynamically select a stylesheet.</p>
        <samp><![CDATA[
<script>
var onSaxonLoad = function() {
    Saxon.run( {
        stylesheet:   "books.xsl",
        source:       "books.xml"
});
</script>]]></samp>
        <h2 class="subtitle">Running XSLT with low-level JavaScript calls</h2>
        <p>The is probably the best choice when running transforms from within existing JavaScript
            code or when integration with other JavaScript libraries is a priority. This also allows
            compiled stylesheets to be reused for subsequent transforms.</p>
        <p>The <a class="bodylink" href="/api">JavaScript API</a> for Saxon-CE gives access to all Saxon-CE's
            processing features and settings, plus utility functions for handling XML in general. It
            is useful when dynamic behavior, stylesheet caching, and interoperability with existing
            JavaScript libraries are important.</p>
        <samp><![CDATA[
<script>
var onSaxonLoad = function() {
    var xsl = Saxon.requestXML("books.xsl");
    var xml = Saxon.requestXML("books.xml");
    var proc = Saxon.newXSLT20Processor(xsl);
    proc.updateHTMLDocument(xml);
});
</script>]]></samp>
        <h2 class="subtitle">Processing Tips</h2>
        <p>When using XSLT 1.0 in the browser, it is common to generate a complete HTML page as
            output from the transformation. With XSLT 2.0, a more effective technique is to write
            multiple fragments of HTML, using them to populate named portions of the HTML page. So
            the initial HTML page will generally contain a skeletal structure of elements such as
                <code>div</code> element, each with an <code>id</code> attribute, waiting to be
            populated by the stylesheet.</p>
    </section>
   <section id="tools" title="Tools">
      <h1>Tools</h1>
        
        <p>Saxon-CE, at its core, is a standard XSLT 2.0 processor. A wide range of tools of free
            and commercial tools are therefore already available to assist you in developing XSLT
            for Saxon-CE. However, because Saxon-CE runs within the browser, other tools will also
            be important: these are explored here.</p>
        <h2 class="subtitle">Web Server</h2>
        <p>In most cases, it's recommended that you use the HTTP protocol to access your resource
            files (XSLT, XML, HTML, CSS etc) from the browser. (Using the file system with
                <code>file://</code> URLs is sometimes possible, but only if you change security and other
            settings in the browser, so we don't recommend it.) Resource files, and Saxon-CE, will
            therefore be hosted by a web-server — either on your local machine or a remote
            server. You will need to ensure that you have the necessary read/write permission, and
            that your editor can perform updates properly, perhaps via the file-system or FTP.</p>
        <p>The choice of web server is down to individual circumstances. The majority of operating
            system distributions include a web server (even on desktop systems - though it's not
            always advertised) that simply needs enabling, but excellent online options are also
            available.</p>
        <h2 class="subtitle">Web Browser</h2>
        <p>The browser hosts Saxon-CE and, in many cases, renders HTML output from Saxon-CE's XSLT
            processor directly to the current page; all modern browsers are well suited to this
            role. From the development perspective, one of the most important parts of the browser
            (apart from developer tools which we cover later) is how resource files are cached and
            how easy it is to reliably refresh the cache when needed. It can be very time-consuming
            if you still see the manifestation of a bug after it was fixed, simply because a stale
            cached resource file is being used. It may also be productive to configure your web
            server to include 'no-cache' instructions within the HTTP header.</p>
        <p>Saxon-CE makes every effort to minimise differences between browsers, but when testing
            you will need to test on all your target browsers; even at the development stage, it's a
            good idea to switch browsers frequently so any issues are picked up early.</p>
        <h2 class="subtitle">Browser Developer Tools</h2>
        <p>All modern browsers come with built-in developer tools, and these can often be
            supplemented with plug-ins available online. Saxon-CE directs errors, timing and
            diagnostics messages to these tools when they're detected. Different logging thresholds
            can be set for Saxon-CE by adding a <code>logLevel</code> query parameter to the host
            page URL. The <a class="bodylink" href="/coding/logging">logging</a> and <a class="bodylink" href="/coding/tracing">tracing</a> sections provide more details.</p>
        <h2 class="subtitle">IDE</h2>
        <p>Using a wide range of loosely-coupled tools can sometimes be a very effective method for
            developing Saxon-CE based applications, but there will be times when more integration
            between tools can aid productivity. Saxon-CE interfaces have been designed to support
            such integration.</p>

        <p>One tool at least, <a href="http://qutoric.com/xmlquire/ce/index.html" class="bodylink">XMLQuire</a>, is
            already publicly available that was extended specifically to exploit Saxon-CE interfaces
            — the emphasis here was on evaluating concepts whilst still providing benefits.
            Its features include:</p>
        <ul>
            <li>
                <p>Automated browser-cache refresh on updates made by the editor</p>
            </li>
            <li>
                <p>Displaying Saxon-CE diagnostics output within the editor - in real-time</p>
            </li>
            <li>
                <p>Highlighting compile-time errors in the XSLT code editor</p>
            </li>
            <li>
                <p>Switching logging level from the editor</p>
            </li>
            <li>
                <p>Auto-creation of new Saxon-CE projects based on project templates</p>
            </li>
            <li>
                <p>Auto-completion/validation of HTML literal result elements within XSLT</p>
            </li>
            <li>
                <p>Whitespace minimisation within the editor</p>
            </li>
        </ul>

        <p>It is hoped that further tools will become available from third parties in due
            course.</p>

        <h2 class="subtitle">Test Tools</h2>
        <p>The extensive range of currently available XSLT and web-specific test tools (including
            those for mobile/tablet devices) will be applicable also to Saxon-CE. Other tools, with
            capabilities enhanced for Saxon-CE will hopefully also become available in a short
            while.</p>

        <p>The test-driver (for Saxonica's internal use) for Saxon-CE's own test suite runs in any
            browser and is actually coded in XSLT 2.0. It therefore exploits Saxon-CE's
            XSLT/JavaScript interoperability and JavaScript API to initiate each XSLT test case from
            within the XSLT.</p>
        <h2 class="subtitle">Future Online Tools</h2>
        <p>As the capabilties of browsers have increased, and with the onset of HTML5, more
            development work has moved online. With Saxon-CE's JavaScript API, there's good
            potential for a variety of specialist tools for editing, analysing and testing XSLT 2.0
            for Saxon-CE.</p>
    </section>
   <section id="licensing" title="Saxon-CE Licensing">
      <h1>Saxon-CE Licensing</h1>
        
        <p>Saxon-CE 1.1 is available as an open-source product, under the Mozilla Public License version 2.0.</p>
 
        <p>Some third-party open source components have been used in the construction of Saxon-CE. These
            use a variety of licenses (BSD-style, Apache) that are compatible with MPL 1.0. Some of these licenses require
            notices to be included in any software distribution: these notices are installed in the same directory
            as the product itself. Some third-party licenses include
            requirements to release details of modifications made to source code; these details are
            provided in comments in the source code modules in question.</p>
        
        <h2 class="subtitle">Third-Party License Notices</h2>
        <p>Saxon-CE uses third-party packages from the following individuals or organisations.</p>
        <table>
            <tr>
                <td>
                    <p>
                        <strong>Package</strong>
                    </p>
                </td>
                <td>
                    <p>
                        <strong>Originator</strong>
                    </p>
                </td>
                <td>
                    <p>
                        <strong>License</strong>
                    </p>
                </td>
            </tr>
            <tr>
                <td>
                    <p>Jakarta regex library</p>
                </td>
                <td>
                    <p>Apache</p>
                </td>
                <td>
                    <p>
                        <a href="http://www.apache.org/licenses/LICENSE-2.0.html" class="bodylink">Apache 2.0</a>
                    </p>
                </td>
            </tr>
            <tr>
                <td>
                    <p>Traces of XPath parser</p>
                </td>
                <td>
                    <p>James Clark</p>
                </td>
                <td>
                    <p>See text</p>
                </td>
            </tr>
            <tr>
                <td>
                    <p>QuickSort</p>
                </td>
                <td>
                    <p>CERN</p>
                </td>
                <td>
                    <p>See text</p>
                </td>
            </tr>
            <tr>
                <td>
                    <p>Unicode Normalization</p>
                </td>
                <td>
                    <p>Unicode, Inc</p>
                </td>
                <td>
                    <p>See text</p>
                </td>
            </tr>
        </table>
        <p>Please download the <a href="file/notices.zip" class="bodylink">notices zip file</a> to see the text of
            the licenses referenced above.</p>
    </section>
   <section id="source" title="Building from Source Code">
      <h1>Building from Source Code</h1>
        
        <p>Source code for Saxon-CE can be downloaded from the <code>github</code> repository at <code>https://github.com/Saxonica/Saxon-CE</code>
        The repository also includes build files, though you may need to customize these to work in your local environment.</p>
        <p>The key tool for building Saxon-CE is the Google Web Toolkit, GWT, which compiles the Java code to Javascript.
        You will need to become familiar with GWT before attempting to build Saxon from source. GWT is probably easiest
        to use as an Eclipse plug-in.</p>
        <p>The most likely reason for building Saxon-CE from source is that you want to integrate it with other GWT applications.
        GWT works at the level of Java source code, and needs access to all the Java source of the complete application. It is possible
        to generate two GWT modules separately but they will then need to communicate with each other using Javascript interfaces.</p>
        <p>At the time of writing, the test material we use for testing Saxon-CE is not released, and in some cases Saxonica does
        not have the right to release it. Bear this in mind if you plan to make modifications to the code.</p>
        <p>If you are interested in contributing to the Saxon-CE project as a committer, please contact Saxonica. We will not accept
        source code submissions unless you (and if appropriate, your employer) agree in writing to license your contributions,
        and we will insist that test material and documentation is submitted in addition to code changes. Given the initial absence of an open-source
        test suite, we will need to discuss the best form for test material to be supplied.</p>
        <p>Saxonica's priorities in taking the product forward are reliability, conformance, usability, and performance in that order. Conformance means
        100% adherence to W3C standards and maximum cross-browser portability. Usability means good APIs, diagnostics, and development tools.
        Performance demands firm attention to keeping the downloaded code size small.
        Contributions will only be accepted if they contribute to these objectives.</p>
        
    </section>
   <section id="help" title="Getting help">
      <h1>Getting help</h1>
        
        <p>Saxon-CE is a new product and in many ways, it represents a new way of developing
            applications. So we fully expect that there will be a learning curve for the user
            community as a whole discovering the best ways of exploiting the technology. And of
            course, despite all our best efforts, there may be bugs. If you find usability problems
            or bugs, please let us know: we can improve the product only if we get feedback.</p>
        <p>Please use the resources of the <a href="http://saxonica.plan.io/projects/saxon-ce" class="bodylink">Saxon-CE project</a> on the
            Saxonica developer community site to report bugs, request help, or check whether
            problems are known. Check the <a class="bodylink" href="/changes">change log for Saxon-CE</a> to
            check whether any updates have been published.</p>
        <p>If you feel you need more detailed help in developing or tuning applications, please
            contact Saxonica to discuss options for training and consultancy.</p>
    </section>
</article>