Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2024-02-20T15:42:25ZSaxonica Developer Community
Planio SaxonJS - Feature #6355 (New): A new instruction that makes a document available by the document(...https://saxonica.plan.io/issues/63552024-02-20T15:42:25ZMartynas Jusevicius
<p><code>ixsl:schedule-action</code> supports <code>@document</code> and <code>@http-request</code>. Both approaches have their advantages.
For <code>@schedule-action</code>:</p>
<blockquote>
<p>The called template can access the documents using the <code>doc()</code>, <code>document()</code>, <code>doc-available()</code>, <code>json-doc()</code>, <code>unparsed-text()</code>, <code>unparsed-text-available()</code>, and <code>unparsed-text-lines()</code> functions as appropriate (the documents will be found in a local cache and will not involve another request to the server).</p>
</blockquote>
<p>For <code>@http-request</code> it's the possibility to fully specify the HTTP request headers. That's what I have been using so har</p>
<p>The problem is that the approaches cannot be combined. In other words, it is not possible to specify HTTP request headers, load documents asynchronously <em>and</em> pass them to templates that use document()
What could be the solution to this?</p>
<p>Adding more options to <code>ixsl:schedule-action</code> seems like it would overload the instruction too much. I'm thinking a better idea could be decoupling the HTTP client functionality from the document caching functionality. That could be achieved using a new instruction that caches a document node under the specified URI, thus making it available for <code>document()</code> calls.</p>
<p>For example:</p>
<pre><code class="xml syntaxhl" data-language="xml"> <span class="nt"><xsl:variable</span> <span class="na">name=</span><span class="s">"href"</span> <span class="na">select=</span><span class="s">"http://example.com/doc.xml"</span> <span class="na">as=</span><span class="s">"xs:string"</span><span class="nt">/></span>
<span class="nt"><ixsl:schedule-action</span> <span class="na">http-request=</span><span class="s">"map{ 'href': $href }"</span><span class="nt">></span>
<span class="nt"><xsl:call-template</span> <span class="na">name=</span><span class="s">"response-callback"</span><span class="nt">></span>
<span class="nt"><xsl:with-param</span> <span class="na">name=</span><span class="s">"href"</span> <span class="na">select=</span><span class="s">"$href"</span><span class="nt">/></span>
<span class="nt"></xsl:call-template></span>
<span class="nt"></ixsk:schedule-action></span>
<span class="nt"><xsl:template</span> <span class="na">name=</span><span class="s">"response-callback"</span><span class="nt">></span>
<span class="nt"><xsl:param</span> <span class="na">name=</span><span class="s">"href"</span> <span class="na">as=</span><span class="s">"xs:string"</span><span class="nt">/></span>
<span class="nt"><ixsl:cache-doc</span> <span class="na">href=</span><span class="s">"$href"</span> <span class="na">select=</span><span class="s">"?body"</span><span class="nt">/></span>
<span class="nt"><xsl:call-template</span> <span class="na">name=</span><span class="s">"legacy"</span><span class="nt">/></span>
<span class="nt"></xsl:template></span>
<span class="nt"><xsl:template</span> <span class="na">name=</span><span class="s">"legacy"</span><span class="nt">></span>
<span class="nt"><xsl:message</span> <span class="na">select=</span><span class="s">"document('http://example.com/doc.xml')"</span><span class="nt">/></span> <span class="c"><!-- retrieved from cache --></span>
<span class="nt"></xsl:template></span>
</code></pre> SaxonJS - Feature #6303 (New): `xsl:result-document` method that replaces `outerHTML`https://saxonica.plan.io/issues/63032023-12-22T10:53:55ZMartynas Jusevicius
<p>Currently <code><xsl:result-document method="ixsl:replace-content"></code> replaces the equivalent of <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML" class="external"><code>innerHTML</code></a>.</p>
<p>Therefore I often find myself doing stuff like this:</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="nt"><xsl:variable</span> <span class="na">name=</span><span class="s">"row"</span> <span class="na">as=</span><span class="s">"node()*"</span><span class="nt">></span>
<span class="nt"><xsl:apply-templates</span> <span class="na">select=</span><span class="s">"$resource"</span> <span class="na">mode=</span><span class="s">"bs2:Row"</span><span class="nt">/></span>
<span class="nt"></xsl:variable></span>
<span class="nt"><xsl:result-document</span> <span class="na">href=</span><span class="s">"?."</span> <span class="na">method=</span><span class="s">"ixsl:replace-content"</span><span class="nt">></span>
<span class="nt"><xsl:copy-of</span> <span class="na">select=</span><span class="s">"$row/*"</span><span class="nt">/></span>
<span class="nt"></xsl:result-document></span>
</code></pre>
<p>Whereas it would be much more convenient to have a new method such as <code>ixsl:replace-self</code> that would replace <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/outerHTML" class="external"><code>outerHTML</code></a>. My example would look much simpler then:</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="nt"><xsl:result-document</span> <span class="na">href=</span><span class="s">"?."</span> <span class="na">method=</span><span class="s">"ixsl:replace-self"</span><span class="nt">></span>
<span class="nt"><xsl:apply-templates</span> <span class="na">select=</span><span class="s">"$resource"</span> <span class="na">mode=</span><span class="s">"bs2:Row"</span><span class="nt">/></span>
<span class="nt"></xsl:result-document></span>
</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> SaxonJS - Feature #6252 (New): Add declaration file for saxon-js to DefinitelyTyped?https://saxonica.plan.io/issues/62522023-11-15T13:06:38ZBoo Zedog
<p>It would be great if we could install a declaration file for saxon-js using <code>npm install --save-dev @types/saxon-js</code></p>
<p>If there is another way to get JSDoc to recognize types for saxon-js please let me know!</p>
<p>Thank you</p> SaxonJS - Bug #6245 (New): broken links in SaxonJS documentation https://saxonica.plan.io/issues/62452023-11-08T14:13:28ZMartin Honnenmartin.honnen@gmx.de
<p><a href="https://www.saxonica.com/saxon-js/documentation2/index.html#!conformance/xslt30" class="external">https://www.saxonica.com/saxon-js/documentation2/index.html#!conformance/xslt30</a> has (at least) two not working links, in the row for <code>vendor-options</code> it says</p>
<blockquote>
<p>Enables syntax extensions for XSLT and XPath, specifically the conditional XSLT extensions described here and the XPath otherwise operator</p>
</blockquote>
<p>where</p>
<ol>
<li>"conditional XSLT extensions described here" links to <a href="https://www.saxonica.com/documentation12/index.html#!extensions/xslt-syntax-extensions" class="external">https://www.saxonica.com/documentation12/index.html#!extensions/xslt-syntax-extensions</a> which gives the error "Error in URI hash-path: Section 'xslt-syntax-extensions' not found in path: extensions/xslt-syntax-extensions"</li>
<li>"otherwise" links to <a href="https://www.saxonica.com/documentation12/index.html#!extensions/syntax-extensions/otherwise" class="external">https://www.saxonica.com/documentation12/index.html#!extensions/syntax-extensions/otherwise</a> which gives a similar error "Error in URI hash-path: Section 'syntax-extensions' not found in path: extensions/syntax-extensions/otherwise"</li>
</ol> SaxonJS - Support #6119 (New): Advice on tracking down log warninghttps://saxonica.plan.io/issues/61192023-07-06T19:21:50ZJohn Cotton
<p>I'm processing '00s of XSL files (with the same XML input) with SaxonJS.</p>
<p>Many throw out this console log:</p>
<p>Cannot compare items of types xs:integer and xs:string: the comparison can succeed only if one of the values is an empty sequence.</p>
<p>It doesn't appear to prevent any output. However, it would be great to know what's causing it.</p>
<p>I've logged the code that's making the warning, but the data at that point is (I think) my "compiled" XSLT, so it's impossible to know where the issue is coming from.</p>
<p>Any advice on finding it?</p>
<p>Regards
John</p> SaxonC - Feature #5833 (New): Add the Path class as argument to method PyQueryProcessor.set_query...https://saxonica.plan.io/issues/58332023-01-18T17:48:12ZO'Neil Delprattoneil@saxonica.com
<p>Following on from the stackoverflow issue: <a href="https://stackoverflow.com/questions/75142854/how-to-use-the-collection-function-with-saxonche/75162395#75162395" class="external">https://stackoverflow.com/questions/75142854/how-to-use-the-collection-function-with-saxonche/75162395#75162395</a></p>
<p>It would be good to add the Path class object (<a href="https://docs.python.org/3/library/pathlib.html" class="external">https://docs.python.org/3/library/pathlib.html</a>) as an argument on the PyQueryProcessor.set_query_base_uri() method. Currently this method only access the URI as a string.</p> SaxonJS - Feature #5784 (New): [enhancement] in-browser debuggerhttps://saxonica.plan.io/issues/57842022-12-25T19:34:51ZSasha Firsov
<p>While there are ways to do the debugging via CLI in node console which is runnable under browser ( like in <a href="https://stackblitz.com/github/EPA-WG/custom-element?file=index.html" class="external">https://stackblitz.com/github/EPA-WG/custom-element?file=index.html</a> ), the development effort for browser plugin creation is significantly bigger in comparison to JS-driven debugger in browser.</p>
<p>Once such support added, the integration with native templating would be seamless. The W3C proposal of native templates as part of Declarative Custom Element is still in baking. But the acceptance of XSLT as the base would rely on debugger availability.</p>
<p>By making SaxonJS be a base for debugger, the Saxon would lay the ground as for expanding the own user base as for positioning itself as a lead in restoring XSLT popularity for UI creation.</p> SaxonJS - Feature #5557 (New): allow clients of SaxonJS to supply a URI resolver functionhttps://saxonica.plan.io/issues/55572022-06-09T23:24:34ZConal Tuohy
<p>SaxonJS doesn't yet allow users to supply their own URI resolver.</p>
<p>Related discussion in XML.com slack instance: <a href="https://xmlcom.slack.com/archives/C011NLXE4DU/p1654568529708119" class="external">https://xmlcom.slack.com/archives/C011NLXE4DU/p1654568529708119</a></p>
<p>I came across the need for such a feature while trying to make resources stored in browser local storage (IndexedDB) available to XSLT running in the browser. I was hoping to be able to supply a resolver that would allow me to handle indexeddb: URIs.</p>
<p>I tried using the browser's "Service Worker" functionality, which can intercept the browser's "fetch" requests, and then either allow them to be handled normally, or else return a promise to fulfill them in some other way. Unfortunately I found that approach is applicable only to URI schemes which the browser already knows about (e.g. http, https, file ...) and also is constrained by some irrelevant security restrictions.</p> SaxonJS - Feature #5011 (New): Bundle browser version in NPM packagehttps://saxonica.plan.io/issues/50112021-05-28T14:01:48ZDaniel Naab
<p>Is there any possibility of distributing the browser version of Saxon-JS in the NPM module?</p>
<p>For context, the package.json may include a <code>browser</code> attribute, that specifies a browser package that web bundlers may use when the library is imported. <a href="https://docs.npmjs.com/cli/v7/configuring-npm/package-json#browser" class="external">https://docs.npmjs.com/cli/v7/configuring-npm/package-json#browser</a></p>
<p>Additionally, a <code>module</code> attribute may specify an ESM module.</p>
<p>Including the browser bundle in the NPM package would ease dependency management, and facilitate library usage in applications with both node.js and browser-based components.</p> SaxonJS - Feature #4736 (New): Add syntax for an external JavaScript object typehttps://saxonica.plan.io/issues/47362020-09-14T15:03:14ZDebbie Lockettdebbie@saxonica.com
<p>We should add a new XPath <code>ItemType</code> for external JavaScript objects, so that type information for variables, etc. can be more specific than just <code>item()</code>. e.g. for storing JavaScript objects returned from calling IXSL extension functions, and global JS functions. (And to avoid conversion to XDM types, where this would otherwise happen.)</p> SaxonJS - Feature #4735 (New): Add multipart support in HTTP clienthttps://saxonica.plan.io/issues/47352020-09-14T12:28:38ZDebbie Lockettdebbie@saxonica.com
<p>As documented, multipart HTTP requests and responses are not currently supported properly by the Saxon-JS HTTP client (<code>ixsl:schedule-action/@http-request</code>).</p>
<p>See <a href="https://www.saxonica.com/saxon-js/documentation/index.html#!development/http" class="external">https://www.saxonica.com/saxon-js/documentation/index.html#!development/http</a> :</p>
<blockquote>
<p>Note that multipart HTTP requests are not currently implemented. Some rules anticipate these being available.</p>
</blockquote>
<blockquote>
<p>Multipart responses are not currently properly handled. A multipart response will be returned as one text/plain body in body (rather than an array of body parts in multipart-bodies.)</p>
</blockquote>
<p>It has always been on the todo list to extend the support for multipart HTTP messages, but there has been no progress on this for some time.</p>
<p>The lack of support is an issue for sending <code>FormData</code> by HTTP. See notes <a class="issue tracker-4 status-3 priority-2 priority-default closed" title="Support: Upgrading AtomGraph application from Saxon-CE to Saxon-JS 2 (Closed)" href="https://saxonica.plan.io/issues/4732#note-4">#4732#note-4</a> and <a class="issue tracker-4 status-3 priority-2 priority-default closed" title="Support: Upgrading AtomGraph application from Saxon-CE to Saxon-JS 2 (Closed)" href="https://saxonica.plan.io/issues/4732#note-6">#4732#note-6</a> in Issue <a class="issue tracker-4 status-3 priority-2 priority-default closed" title="Status: Closed" href="https://saxonica.plan.io/issues/4732">Support #4732: Upgrading AtomGraph application from Saxon-CE to Saxon-JS 2</a>.</p> W3C QT Specifications - Bug #4222 (New): [xslt30] Visibility of xsl:paramhttps://saxonica.plan.io/issues/42222019-05-16T23:00:16ZMichael Kaymike@saxonica.com
<p>The XSLT 3,0 spec makes confusingly inconsistent statements about the visibility of global parameters.</p>
<ul>
<li>
<p>The grammar for <code>xsl:param</code> does not allow a <code>visibility</code> attribute</p>
</li>
<li>
<p>In §3.5.3.1, under <code>xsl:expose</code>, we say "The visibility of a variable declared using an <code>xsl:param</code> element is always public."</p>
</li>
<li>
<p>§9.6 (Static parameters) says: "When the static attribute [of <code>xsl:param</code>] is present with the value yes, the visibility attribute must not have a value other than <code>private</code>." But in fact, no visibility attribute is allowed by the grammar. It is clear in this section that the intent is for static parameters to always be private: there is a note explaining why (specifically, so they cannot be overridden, which is necessary to allow separate compilation of packages; however, I don't see why visibility="final" can't be allowed, which would achieve the same aim.</p>
</li>
</ul>
<p>I think one aspect of this that the spec fails to address is: when package P "uses" package Q, it is presumably using a version of Q whose static parameters have been bound to particular values. But there is no way for P to say what these values should be. There can be two compiled instances of Q with different values bound to the static parameters, and the effect of using these two instances is likely to be quite different.</p>