Revision 120210 of XSLT 2.0

  • Revision slug: XSLT_2.0
  • Revision title: XSLT 2.0
  • Revision id: 120210
  • Created:
  • Creator: Zearin
  • Is current revision? No
  • Comment Editing phrasing for clarity (again).; 23 words added, 27 words removed

Revision Content

For users

Although XSLT 2.0 is not natively supported in Firefox, it is possible (via Saxon-B) to perform XSLT 2.0.  This might happen via the XSL Results extension, or within other extensions using the approach taken in its code (see below).

The extension author hopes to soon add support for having XSLT performed automatically when visiting a page with the appropriate XSLT processing instruction (and which isn't processed by Firefox's own XSLT 1.0 processor).

For developers

While it is possible to use the extension's approach to add XSLT 2.0 support to an extension (or Saxon-B's XQuery or XPath), it is fairly complicated at this time.  This is especially true if one is unfamiliar with Java, largely due to a bug in LiveConnect with try-catch blocks.  As a result, it's necessary to write Java wrapper classes rather relying on JavaScript's own try-catch blocks; otherwise, the code might fail upon encountering a Java exception and become unusable until restart.

Until the bug is fixed, the following would be necessary:

  1. Rewrite at least all of the public classes in order to expose the full API
  2. Handle exceptions on the Java side
  3. Return errors as a string or object for JavaScript handle in XSLT (or XQuery) processing
  4. A wrapper (or direct rewrite of Saxon code) would also need to take into account that if a method would return a given object, that object should also be a wrapped object so that it can also return error messages, in the event that the JavaScript tries to act on the Java object and an exception is returned.

Also, the code does not currently work on the Mac (perhaps due to its lagging Java support). However, if Saxon-B were completely compiled in Java 5 (rather than the current mixture of JDK 1.4 and 5), the Saxon-B library author suggests this might solve the problem.  Any Java developers are most welcome to help fix this!  

Interested?  Leave a message on the discussion page.

{{ languages( { "fr": "fr/XSLT_2.0" } ) }}

Revision Source

<h3 name="For_users">For users</h3>
<p>Although XSLT 2.0 is not natively supported in Firefox, it is possible (via <a class="external" href="http://saxonica.com">Saxon-B</a>) to perform <a class="external" href="http://www.w3.org/TR/xslt20/">XSLT 2.0</a>.  This might happen via the <a class="link-https" href="https://addons.mozilla.org/en-US/firefox/addon/5023">XSL Results</a> extension, or within other extensions using the approach taken in its code (see below).</p>
<p>The extension author hopes to soon add support for having XSLT performed automatically when visiting a page with the appropriate XSLT processing instruction (and which isn't processed by Firefox's own XSLT 1.0 processor).</p>
<h3 name="For_developers">For developers</h3>
<p>While it is possible to use the extension's approach to add XSLT 2.0 support to an extension (or Saxon-B's <a href="/en/XQuery" title="en/XQuery">XQuery</a> or <a href="/en/XPath" title="en/XPath">XPath</a>), it is fairly complicated at this time.  This is especially true if one is unfamiliar with Java, largely due to <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=391642">a bug</a> in <a href="/en/LiveConnect" title="en/LiveConnect">LiveConnect</a> with <code>try-catch</code> blocks.  As a result, it's necessary to write Java wrapper classes rather relying on JavaScript's own <code>try-catch</code> blocks; otherwise, the code might fail upon encountering a Java exception and become unusable until restart.</p>
<p>Until the bug is fixed, the following would be necessary:</p>
<ol> <li>Rewrite at least all of the public classes in order to expose the full API</li> <li>Handle exceptions on the Java side</li> <li>Return errors as a <code>string</code> or <code>object</code> for JavaScript handle in XSLT (or XQuery) processing</li> <li>A wrapper (or direct rewrite of Saxon code) would also need to take into account that if a method would return a given object, that object should also be a wrapped object so that it can also return error messages, in the event that the JavaScript tries to act on the Java object and an exception is returned.</li>
</ol>
<p>Also, the code does not currently work on the Mac (perhaps due to its lagging Java support). However, if Saxon-B were completely compiled in Java 5 (rather than the current mixture of JDK 1.4 and 5), the Saxon-B library author suggests this might solve the problem.  Any Java developers are most welcome to help fix this!  </p>
<p>Interested?  Leave a message on the discussion page.</p>
<p>{{ languages( { "fr": "fr/XSLT_2.0" } ) }}</p>
Revert to this revision