update based on https://github.com/mdn/yari/issues/2028

1 files changed, 0 insertions, 13 deletions

diff --git a/files/zh-cn/xslt_2.0/index.html b/files/zh-cn/xslt_2.0/index.html
deleted file mode 100644
index 3a2d4bdd87..0000000000
--- a/files/zh-cn/xslt_2.0/index.html
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: XSLT 2.0
-slug: XSLT_2.0
-translation_of: Mozilla/Tech/XSLT_2.0
----
-<h3 id="For_users" name="For_users">For users</h3>
-<p>Although XSLT 2.0 is not supported natively 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>, either as a regular user using the <a class="link-https" href="https://addons.mozilla.org/en-US/firefox/addon/5023">XSL Results</a> extension, or within one's own 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 containing a processing instruction for XSLT (and which was not already performed by Firefox's own 1.0 XSLT processor).</p>
-<h3 id="For_developers" name="For_developers">For developers</h3>
-<p>While it is possible to use the approach taken in the extension's code to add XSLT 2.0 support to one's own extension (or also Saxon-B's <a href="cn/XQuery">XQuery</a> or <a href="cn/XPath">XPath</a>), at this time, it is fairly complicated, especially if one is not familiar with Java, due largely to the fact that there is <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=391642">a bug</a> in <a href="cn/LiveConnect">LiveConnect</a> with try-catch blocks, thus necessitating one to write one's own Java wrapper classes rather than to rely on JavaScript's own try-catch blocks (otherwise, the code might fail upon encountering a Java exception and be unusable again until restart).</p>
-<p>If the bug is not fixed, in order to expose the full API, one would need to rewrite at least all of the public classes, handling exceptions on the Java side and returning an error string or object so that the JavaScript side could deal with any errors in XSLT (or XQuery) processing. However, a wrapper (or a direct rewrite of the 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.</p>
-<p>Also, perhaps due to lagging Java support on the Mac, the code currently does not work on the Mac. However, if someone familiar with Java can try compiling Saxon-B completely in Java 5 (rather than its current mixture of JDK 1.4 and 5, the Saxon-B library author suggests this might solve the problem--any Java developers would be most welcome to help me (the XSL Results extension author) fix this). (You can leave a message on the discussion page.)</p>
-<p></p>