Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2024-03-27T11:18:36ZSaxonica Developer Community
Planio Saxon - Bug #6379 (New): Default implementation of fn:deep-equalhttps://saxonica.plan.io/issues/63792024-03-27T11:18:36ZNorm Tovey-Walsh
<p>I happened to trace my way through a call to deep equal in Saxon HE 12.4 and I was a little bit surprised to find that it's using the <code>DeepEqual40</code> implementation. I wonder if that was intentional...</p> SaxonJS - Bug #6374 (New): saxon.compile removed in 2.6+?https://saxonica.plan.io/issues/63742024-03-19T09:54:05ZJai B
<p>Hi,</p>
<p>I've always used the <code>saxon.compile</code> function to generate sef files in code. I know it's undocumented but IIRC it was shown in the command line docs or something.</p>
<p>Basically I cache the compiled sef so I don't have to recompile everytime I want to do a transform and I don't want to pre-transform my XSLT files on the command line, nor do I have any desire to use the Java version for that part, the JS compiler has worked amazingly!</p>
<p>My web app does server side transformations with node; anytime it sees the XSLT change, it runs a compile to generate and cache a new sef to use for subsequent transformations. I can't cache the result of the transformation either since the data is dynamic, of course.</p>
<p>Perhaps I'm missing something or missing some changes, but this has worked awesome for years and only just noticed things breaking when redeploying some stuff and npm updating to 2.6.0 and getting an error that the function doesn't exist.</p>
<p>When I was initially implementing this, I know I spent a fair bit of time trying to figure this part out and ensure I was doing things right; I think I scoped the code that generates the sef on command line to find the function in the first place and was surprised it wasn't actually documented/available anyway.</p>
<p>Thanks again for SaxonJS!</p> SaxonC - Bug #6353 (New): Unicode characters in filenames are causing errors in Windowshttps://saxonica.plan.io/issues/63532024-02-20T09:38:55ZMatt Patterson
<p>As reported by a user in this SO post comment: <a href="https://stackoverflow.com/questions/77962974/saxon-xslt-processing-thousands-of-xml-files-in-a-complex-tree-structure/77963410?noredirect=1#comment137525632_77963410" class="external">https://stackoverflow.com/questions/77962974/saxon-xslt-processing-thousands-of-xml-files-in-a-complex-tree-structure/77963410?noredirect=1#comment137525632_77963410</a></p>
<p>Thanks to silfer1200 and Martin Honnen for reporting.</p>
<p>If you try to pass a filename containing a unicode char with a multi-byte representation in UTF-8 into Saxon C's python layer some weird mangling happens and it looks like the string gets decomposed to a bytestream and then recomposed into a string with each byte considered a complete character.</p>
<p>Given a very simple test setup with the following XML file and python script, this will error out every time it's run on Windows. On macOS it's fine.</p>
<p><code>test.py</code>:</p>
<pre><code class="python syntaxhl" data-language="python"><span class="kn">import</span> <span class="nn">os</span>
<span class="kn">import</span> <span class="nn">sys</span>
<span class="kn">from</span> <span class="nn">saxonche</span> <span class="kn">import</span> <span class="n">PySaxonProcessor</span>
<span class="n">dir_path</span> <span class="o">=</span> <span class="n">os</span><span class="p">.</span><span class="n">path</span><span class="p">.</span><span class="n">dirname</span><span class="p">(</span><span class="n">os</span><span class="p">.</span><span class="n">path</span><span class="p">.</span><span class="n">realpath</span><span class="p">(</span><span class="n">__file__</span><span class="p">))</span>
<span class="k">print</span><span class="p">(</span><span class="n">sys</span><span class="p">.</span><span class="n">getdefaultencoding</span><span class="p">())</span>
<span class="k">print</span><span class="p">(</span><span class="n">sys</span><span class="p">.</span><span class="n">getfilesystemencoding</span><span class="p">())</span>
<span class="k">with</span> <span class="n">PySaxonProcessor</span><span class="p">()</span> <span class="k">as</span> <span class="n">saxon_proc</span><span class="p">:</span>
<span class="n">xml</span> <span class="o">=</span> <span class="n">saxon_proc</span><span class="p">.</span><span class="n">parse_xml</span><span class="p">(</span><span class="n">xml_file_name</span><span class="o">=</span><span class="n">os</span><span class="p">.</span><span class="n">path</span><span class="p">.</span><span class="n">join</span><span class="p">(</span><span class="n">dir_path</span><span class="p">,</span> <span class="s">'köln.xml'</span><span class="p">))</span>
<span class="k">print</span><span class="p">(</span><span class="n">xml</span><span class="p">)</span>
</code></pre>
<p><code>köln.xml</code>:</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="cp"><?xml version="1.0" encoding="utf-8"?></span>
<span class="nt"><hello></span>Köln<span class="nt"></hello></span>
</code></pre>
<p>Windows:</p>
<pre><code>(test-venv) C:\Saxonica\unicode>python test.py
utf-8
utf-8
Traceback (most recent call last):
File "C:\Saxonica\unicode\test.py", line 11, in <module>
xml = saxon_proc.parse_xml(xml_file_name=os.path.join(dir_path, 'köln.xml'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "python_saxon\saxonc.pyx", line 868, in saxonche.PySaxonProcessor.parse_xml
saxonche.PySaxonApiError: Unable to resolve <C:\Saxonica\unicode\köln.xml> into a Source. Line number: -1
</code></pre>
<p>macOS:</p>
<pre><code>$ python test.py
utf-8
utf-8
<hello>Köln</hello>
<hello>Köln</hello>
</code></pre> SaxonJS - Bug #6346 (New): NPE with replace() on SaxonJS2.6 when exported under 4.0-support condi...https://saxonica.plan.io/issues/63462024-02-14T14:05:50ZJohn Lumleyjohn@saxonica.com
<p>When exporting a stylesheet (either 3.0 or 4.0) for SaxonJS 2.6, using SaxonEE 12.4 running under <code> --allowSyntaxExtensions:on</code>,
a three-argument call on <code>replace()</code> (that is with the fourth <code>$flags</code> argument to default to the empty string), at runtime a null pointer expection is thrown when attempting to retrieve the flags:</p>
<pre><code class="javascript syntaxhl" data-language="javascript"><span class="kd">const</span> <span class="nx">flags</span> <span class="o">=</span> <span class="nx">args</span><span class="p">[</span><span class="mi">3</span><span class="p">]</span> <span class="p">?</span> <span class="nx">args</span><span class="p">[</span><span class="mi">3</span><span class="p">].</span><span class="nx">next</span><span class="p">().</span><span class="nx">toString</span><span class="p">()</span> <span class="p">:</span> <span class="dl">""</span><span class="p">;</span>
</code></pre>
<p>The <code>next()</code> returns a null.</p>
<p>Without <code>allowSyntaxExtensions</code> or with the fourth argument supplied, the function behaves as expected.</p>
<p>Sample stylesheet, compiled SEF and web page attached</p> Saxon - Bug #6343 (New): Function Coercion is not always appliedhttps://saxonica.plan.io/issues/63432024-02-11T23:27:14ZMichael Kaymike@saxonica.com
<p>I have created the following test case FunctionCall-058:</p>
<pre><code> declare function local:f($callback as function(xs:integer) as xs:boolean) as xs:boolean {
$callback(year-from-date(current-date()) div 1900)
};
local:f(function($d as xs:decimal) as xs:boolean { $d lt 0 })
</code></pre>
<p>This should fail because the <code>$callback</code> function requires an xs:integer but the supplied value (the result of the integer division) is an xs:decimal.</p>
<p>What is supposed to happen according to the spec is that the supplied function (which accepts an x:decimal) is coerced to the required type (which does not). The means that the function actually supplied to the $callback parameter is effectively:</p>
<pre><code>function($d1 as xs:integer) as xs:boolean {
function($d2 as xs:decimal) as xs:boolean { $d2 lt 0 } ($d1)
}
</code></pre>
<p>which should fail with a type error when called supplying an <code>xs:decimal</code>.</p>
<p>However, because the value supplied to the <code>$callback</code> parameter is an instance of the required type, Saxon skips the process of function coercion wrongly believing it to be unnecessary; his has the effect that the type error is not detected.</p> SaxonC - Bug #6325 (New): saxonche.PySaxonApiError: Null found in Java string conversation. Line ...https://saxonica.plan.io/issues/63252024-01-19T12:32:10ZO'Neil Delprattoneil@saxonica.com
<p>Reported by user via email.</p>
<p>The user is migrating from saxonpy to saxonche.</p>
<p>Error reported:</p>
<pre><code>saxonche.PySaxonApiError: Null found in Java string conversation. Line number: -1
</code></pre>
<p>You can find the Git repository with the relevant files and code here:</p>
<p><a href="https://github.com/sirisha09-till/xml2dita/tree/main/xml2dita" class="external">https://github.com/sirisha09-till/xml2dita/tree/main/xml2dita</a></p> Saxon - Bug #6307 (New): Saxon (HE; Java) trace missing xsl:accumulator and xsl:accumulator-rule,...https://saxonica.plan.io/issues/63072023-12-27T21:52:00ZA Galtman
<ul>
<li>Is the trace supposed to mark xsl:accumulator as hit?</li>
<li>Is the trace supposed to mark xsl:accumulator-rule as hit?</li>
<li>I definitely expect descendant elements of xsl:accumulator-rule to be marked as hit, and I'm not seeing them in Saxon 12.4. Saxon 9.9.1.8 correctly lists the descendants of xsl:accumulator-rule.</li>
</ul>
<p>I'm attaching a file that includes the code, the Saxon arguments I used, and the traces I got from Saxon 9.9.1.8 and 12.4.</p> Saxon - Bug #6305 (New): XPathException "The stylesheet module includes/imports itself directly o...https://saxonica.plan.io/issues/63052023-12-22T15:02:48ZGerben Abbinkgerben.abbink@gmail.com
<p>I use an ErrorReporter with XsltCompiler, like this:</p>
<pre><code>XsltCompiler compiler = processor.newXsltCompiler();
compiler.setErrorReporter(...);
</code></pre>
<p>Usually, XPathExceptions have a Location to identify the error in the file.</p>
<p>But, when I use this template, there is no location information:</p>
<pre><code><?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href=""/>
</xsl:stylesheet>
</code></pre> Saxon - Bug #6302 (New): Saxon (HE; Java) trace not well-formed when XSLT uses transform functionhttps://saxonica.plan.io/issues/63022023-12-21T19:56:45ZA Galtman
<p>(I alluded to this in my 12/21/23 comment in <a href="https://saxonica.plan.io/issues/6295" class="external">https://saxonica.plan.io/issues/6295</a> but it seems different enough that I'm making a separate issue for it rather than assume that the fix for 6295 is enough.)</p>
<p>The <code>transform()</code> function seems to cause the Saxon trace not to be well-formed.</p>
<a name="Sample-XSLT-1-transform-functionxsl"></a>
<h3 >Sample XSLT 1, transform-function.xsl<a href="#Sample-XSLT-1-transform-functionxsl" class="wiki-anchor">¶</a></h3>
<pre><code><?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:my="my-ns"
exclude-result-prefixes="#all"
version="3.0">
<xsl:template name="xsl:initial-template">
<xsl:variable name="transform-options" as="map(xs:string, item()*)">
<xsl:map>
<xsl:map-entry key="'delivery-format'" select="'raw'"/>
<xsl:map-entry key="'stylesheet-location'">target-stylesheet-small.xsl</xsl:map-entry>
<xsl:map-entry key="'function-params'" select="[()]"/>
<xsl:map-entry key="'initial-function'" select="QName('my-ns', 'my:fcn')"/>
</xsl:map>
</xsl:variable>
<xsl:sequence select="transform($transform-options)?output"/>
</xsl:template>
</xsl:stylesheet>
</code></pre>
<a name="Sample-XSLT-2-target-stylesheet-smallxsl"></a>
<h3 >Sample XSLT 2, target-stylesheet-small.xsl<a href="#Sample-XSLT-2-target-stylesheet-smallxsl" class="wiki-anchor">¶</a></h3>
<pre><code><?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fn="http://www.w3.org/2005/xpath-functions"
xmlns:my="my-ns"
exclude-result-prefixes="#all"
version="3.0">
<xsl:function name="my:fcn" visibility="public" as="xs:string">
<xsl:param name="p" as="empty-sequence()"/>
<xsl:sequence select="'output'"/>
</xsl:function>
</xsl:stylesheet>
</code></pre>
<a name="Saxon-command"></a>
<h3 >Saxon command<a href="#Saxon-command" class="wiki-anchor">¶</a></h3>
<pre><code>java -cp "%SAXON_CP%" net.sf.saxon.Transform -opt:0 -T -Tlevel:high -it -xsl:transform-function.xsl 2>transform-function-traceresult.xml
</code></pre>
<p>I'm using Saxon-HE 12.4.</p>
<a name="Trace-Result"></a>
<h3 >Trace Result<a href="#Trace-Result" class="wiki-anchor">¶</a></h3>
<pre><code><trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="xsl:initial-template" line="9" column="45" module="transform-function.xsl">
<xsl:variable name="transform-options" line="10" column="73" module="transform-function.xsl">
<trace text="target-stylesheet-small.xsl" line="13" column="52" module="transform-function.xsl">
</trace>
<trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:function arity="1" name="my:fcn" line="9" column="66" module="target-stylesheet-small.xsl">
</xsl:function>
</xsl:variable>
</xsl:template>
</trace>
</code></pre> SaxonC - Bug #6299 (New): Add a Makefile to the release for building of the SaxonC C/C++ API libraryhttps://saxonica.plan.io/issues/62992023-12-20T13:02:23ZO'Neil Delprattoneil@saxonica.com
<p>Reported by user here <a href="https://stackoverflow.com/questions/77684816/undefined-reference-error-when-link-to-saxon-library-in-c/77690492#77690492" class="external">https://stackoverflow.com/questions/77684816/undefined-reference-error-when-link-to-saxon-library-in-c/77690492#77690492</a></p>
<p>The SaxonC release should contain a MakeFile to build the C/C++ library. This is something we attempted to do long time ago, but for some reason we proceed with its use. Since we are now using Graalvm we should use a Makefile.</p> SaxonJS - Bug #6298 (New): base-uri() value does not update together with DOMhttps://saxonica.plan.io/issues/62982023-12-19T23:34:51ZMartynas Jusevicius
<p>My SaxonJS code replaces large chunks of DOM with content loaded from different documents. DOM's baseURI property returns the source document's URL, but <code>base-uri()</code> does not always seem to do that. Which can lead to a stale value, probably because the DOM is updated?</p>
<p>This is my observation of the discrepancy:</p>
<pre><code>ixsl:get(., 'baseURI'): https://localhost:4443/7b386331-5a82-46ab-820b-38df78a91456/ SaxonJS2.rt.js:785:84
base-uri(): https://localhost:4443/ SaxonJS2.rt.js:785:84
ixsl:location(): https://localhost:4443/7b386331-5a82-46ab-820b-38df78a91456/
</code></pre> SaxonC - Bug #6297 (New): 12.4.1 command build errors on CentOS 7https://saxonica.plan.io/issues/62972023-12-19T11:50:46ZTony Graham
<p>Running <code>build-saxonc-commands.sh</code> on CentOS 7 generated errors about the C version, such as:</p>
<pre><code>Transform.c: In function ‘transform’:
Transform.c:33:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 1; i < argc; i++) {
^
Transform.c:33:3: note: use option -std=c99 or -std=gnu99 to compile your code
</code></pre>
<p>After adding <code>-std=c99</code> to the GCC command lines, there were errors about <code>int64_t</code>, such as:</p>
<pre><code>In file included from ../Saxon.C.API/SaxonCGlue.c:1:0:
../Saxon.C.API/SaxonCGlue.h:92:3: error: unknown type name ‘int64_t’
int64_t value; /*!< Internal use only. The value of the parameter points
^
</code></pre>
<p>That was worked around by adding <code>#include <stdint.h></code> for <code>__LINUX__</code> and <code>__APPLE__</code> in <code>SaxonCGlue.h</code>. I don't know whether <code>#include <stdint.h></code> would be necessary for <code>__APPLE__</code>.</p>
<p>Also, it's not clear why <code>#include <stdio.h></code> is included a second time for <code>__LINUX__</code> and <code>__APPLE__</code>.</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- build-saxonc-commands.sh~ 2023-12-01 12:17:46.000000000 +0000
</span><span class="gi">+++ build-saxonc-commands.sh 2023-12-19 08:52:51.329869064 +0000
</span><span class="p">@@ -4,15 +4,15 @@</span>
parent_path=$( cd "$(dirname "$0")" ; pwd -P )
library_dir=${1-$(pwd -P)}/../libs/nix
#cd "$parent_path"
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm -c ../Saxon.C.API/SaxonCGlue.c -o SaxonCGlue.o $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm -c ../Saxon.C.API/SaxonCGlue.c -o SaxonCGlue.o $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Transform.c -o transform -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Transform.c -o transform -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Query.c -o query -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Query.c -o query -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
<span class="gd">-gcc -m64 -fPIC -I../Saxon.C.API/graalvm Gizmo.c -o gizmo -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Gizmo.c -o gizmo -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span>
if [ -f Validate.c ]; then
<span class="gd">- gcc -m64 -fPIC -I../Saxon.C.API/graalvm Validate.c -o validate -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span><span class="gi">+ gcc -std=c99 -m64 -fPIC -I../Saxon.C.API/graalvm Validate.c -o validate -ldl -lc SaxonCGlue.o -L$library_dir -lsaxon-hec-12.4.1 $1
</span> fi
</code></pre>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- SaxonCGlue.h~ 2023-12-01 12:17:48.000000000 +0000
</span><span class="gi">+++ SaxonCGlue.h 2023-12-19 09:00:42.996931099 +0000
</span><span class="p">@@ -17,6 +17,7 @@</span>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
<span class="gi">+#include <stdint.h>
</span> #else
#include <stdint.h>
#include <windows.h>
</code></pre> SaxonC - Bug #6291 (New): Warnings for invalid keywords from transform_to_string methods on PyXsl...https://saxonica.plan.io/issues/62912023-12-15T15:06:24ZDebbie Lockettdebbie@saxonica.com
<p>The documentation for the <code>PyXslt30Processor</code> <code>transform_to_string</code> method says that the keywords <code>source_file</code> and <code>stylesheet_file</code> are required. The method currently raises a warning only when <code>len(kwds) == 0</code>. It would be better to raise a warning precisely when <code>source_file</code> and <code>stylesheet_file</code> are not both supplied.</p>
<p>Meanwhile for <code>transform_to_string</code> on <code>PyXsltExecutable</code>, there is some other confusion about supplied keywords. Here only one of <code>source_file</code> or <code>xdm_node</code> can be supplied, and a warning is raised if both are (I committed a change here yesterday to check for precisely both of these keywords, rather than <code>len(kwds) > 0</code>). (Note that it is OK to supply neither.) The other possible keywords are <code>base_output_uri</code> and <code>encoding</code>. It looks like you'll currently get a (unhelpfully worded) warning if you try to supply only <code>encoding</code> - but that should be permitted.</p> SaxonC - Bug #6276 (New): https://pypi.org/project/saxonche/ claims current print(proc.version) g...https://saxonica.plan.io/issues/62762023-12-02T10:58:42ZMartin Honnenmartin.honnen@gmx.de
<p>I am not sure this is a build problem/quirk or a documentation problem/quirk but <a href="https://pypi.org/project/saxonche/" class="external">https://pypi.org/project/saxonche/</a> claims current <code>print(proc.version)</code> would give <code>SaxonC-HE 12.4.1 from Saxonica</code> while even with 12.4.1 the output remains at <code>SaxonC-HE 12.4 from Saxonica</code>.</p>
<p>But the inconsistency between the documentation of the wheel on PyPi and its version number and the actual result might be confusing.</p> Saxon - Bug #6263 (New): Test case try-031 fails under Saxon-HE (try/catch with lazy evaluation)https://saxonica.plan.io/issues/62632023-11-28T11:01:55ZMichael Kaymike@saxonica.com
<p>The XSLT 3.0 test case try-031 is failing under Saxon-HE. The essence of the failure is that in the construct</p>
<pre><code><xsl:variable name="p" select="...."/>
<xsl:try>
<xsl:value-of select="$p"/>
<xsl:catch>
<caught/>
</xsl:catch>
</xsl:try>
</code></pre>
<p>an error occurring during lazy evaluation of $p is caught by the try/catch when it should not be.</p>
<p>The test is failing in the candidate 12.4 release but also fails in earlier releases.</p>