Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2024-03-19T14:58:59ZSaxonica Developer Community
Planio SaxonJS - Feature #6375 (New): Support popular DOM implementationshttps://saxonica.plan.io/issues/63752024-03-19T14:58:59ZMichael Kaymike@saxonica.com
<p>The "barrier to entry" for SaxonJS would be reduced if we were able to promote it as an API for executing XPath 3.1 against popular DOM implementations -- xmldom, jsdom, slimdom, ...</p>
<p>I don't think there's any fundamental barrier to supporting external DOM implementations, it just needs testing.</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> 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 - 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> SaxonJS - Bug #4914 (New): Parameters supplied in SaxonJS.transform options not converted correct...https://saxonica.plan.io/issues/49142021-02-18T17:57:50ZDebbie Lockettdebbie@saxonica.com
<p>Using the <code>stylesheetParams</code> option for <code>SaxonJS.transform</code>, strong conversion (as documented at <a href="https://www.saxonica.com/saxon-js/documentation/index.html#!xdm/conversions" class="external">https://www.saxonica.com/saxon-js/documentation/index.html#!xdm/conversions</a>) for a stylesheet parameter with a typed array required type (i.e. which specifies the types of the array members), e.g. <code>array(xs:string)</code> or <code>array(xs:integer)</code>, does not work correctly.</p>
<p>For instance supplying:</p>
<pre><code class="javascript syntaxhl" data-language="javascript"><span class="dl">"</span><span class="s2">stylesheetParams</span><span class="dl">"</span><span class="p">:</span> <span class="p">{</span><span class="dl">"</span><span class="s2">arrayStr</span><span class="dl">"</span><span class="p">:</span> <span class="p">[[</span><span class="dl">"</span><span class="s2">a</span><span class="dl">"</span><span class="p">,</span><span class="dl">"</span><span class="s2">b</span><span class="dl">"</span><span class="p">,</span><span class="dl">"</span><span class="s2">c</span><span class="dl">"</span><span class="p">]]}</span>
</code></pre>
<p>For the stylesheet parameter:</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="nt"><xsl:param</span> <span class="na">name=</span><span class="s">"arrayStr"</span> <span class="na">select=</span><span class="s">"['x','y']"</span> <span class="na">as=</span><span class="s">"array(xs:string)"</span><span class="nt">/></span>
</code></pre>
<p>Results in the error:</p>
<pre><code class="text syntaxhl" data-language="text">"Supplied value [xs:untypedAtomic('a'),xs:untypedAtomic('b'),xs:untypedAtomic('c')] does not match required type array(xs:string) in stylesheet parameter Q{}arrayStr"
</code></pre>
<p>It appears that the function conversion rules have not been applied to the array members, so they have not been cast to the required type.</p> SaxonJS - Bug #4815 (New): Conversion of XDM maps to JS objectshttps://saxonica.plan.io/issues/48152020-10-30T10:05:35ZDebbie Lockettdebbie@saxonica.com
<p>On the XML.com Slack general channel, Pieter Lamers asked the following:</p>
<blockquote>
<p>I'm trying to get scrollIntoView to work smoothly. Now, <code>ixsl:call($target, 'scrollIntoView',[])</code> works, but I don't know how to pass the <code>ScrollIntoViewOptions</code> into the array. [...] This is what I would typically want to achieve:
<code>element.scrollIntoView({behavior: "smooth", block: "start", inline: "nearest"});</code></p>
</blockquote>
<p>Intuitively, users expect to be able to supply a <code>map(*)</code> in the array for the 3rd argument to <code>ixsl:call</code>; but this will not work as expected, because the XDM to JS conversion does not automatically convert XDM maps to JavaScript object literals. (See <a href="https://www.saxonica.com/saxon-js/documentation/index.html#!xdm/conversions" class="external">https://www.saxonica.com/saxon-js/documentation/index.html#!xdm/conversions</a>). Instead if an XDM map is supplied here, it will be converted to a "wrapped XDM map object", which the <code>scrollIntoView</code> JavaScript method simply ignores.</p>
<p>Martin Honnen suggested a couple of work arounds:</p>
<blockquote>
<p>you might want to set up a Javascript variable <code>var options = {behavior: "smooth", block: "start", inline: "nearest"};</code> and pass it to the XSLT with e.g.
<code>SaxonJS.transform({ stylesheetLocation: 'sheet1.sef.json', sourceLocation: 'sample1.xml', stylesheetParams: { options: options } } )</code>
In your XSLT you then use <code>ixsl:call(., 'scrollIntoView', [ $options])</code> and declare <code><xsl:param name="options" required="true"/></code></p>
</blockquote>
<blockquote>
<p>Or construct the scroll options inside XSLT with e.g. <code><xsl:param name="scrollOptions" as="xs:string" expand-text="no">{ "behavior" : "smooth", "block" : "start", "inline": "nearest" }</xsl:param></code> and <code>ixsl:call(., 'scrollIntoView', [ ixsl:window() => ixsl:call('JSON.parse', [ $scrollOptions ]) ])</code>. Seems a bit cumbersome, not sure whether there is a simple way to convert an XdmMap into a JavaScript object inside of Saxon-JS.</p>
</blockquote>
<p>Indeed currently our recommended approach is that if you really want/need to work with JavaScript objects, then create them in the JavaScript space, since converting from XDM maps is not possible. But either: (a) this needs to be made clearer in the documentation; or (b) as Martin alludes, perhaps we should actually be providing a way to ask for (certain) XDM maps to be converted to JavaScript objects from the XSLT (e.g. with a new IXSL function).</p> SaxonJS - Bug #4763 (New): fn:transform() - the post-process option is ignoredhttps://saxonica.plan.io/issues/47632020-09-28T23:23:12ZMichael Kaymike@saxonica.com
<p>The implementation of fn:transform ignores the post-process option.</p>
<p>This causes failure of tests fn-transform-079. -080, and -081.</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> SaxonJS - Feature #4655 (AwaitingInfo): Standard-ESM importshttps://saxonica.plan.io/issues/46552020-07-24T18:15:30ZMichael Kaymike@saxonica.com
<p>Request received from Max Fechner by email:</p>
<p>Thank you for developing saxonJS!</p>
<p>It would be great if you could support standard-esm imports like</p>
<pre><code>import saxonJS from 'http://www.saxonica.com/saxon.js'
</code></pre>
<p>this would work in *deno as well as nodejs as well as modern browsers!</p>
<p>thank you for considering this proposal!</p>
<p>best, Max Fechner</p> SaxonJS - Bug #4604 (New): SaxonJS.transform() API - documentation and usability issueshttps://saxonica.plan.io/issues/46042020-06-18T14:49:08ZMichael Kaymike@saxonica.com
<ul>
<li>
<p>It seems we accept the <code>globalContextItem</code> option but this is not documented. (And in particular, it's not documented what conversion is applied, especially in the presence of an <code>xsl:global-context-item</code> declaration that specifies the required type.)</p>
</li>
<li>
<p>Switching to using a stylesheet parameter, with a declared type of <code>array(map(xs:string, xs:anyAtomicType))</code> I was hoping to be able to pass a Javascript array of objects. No such luck. I ended up converting the value to lexical JSON and then parsing the JSON from the XSLT code.</p>
</li>
<li>
<p>I tried specifying <code>{destination: "file", baseOutputURI: "profile.html"}</code> and it rejects "profile.html" as an invalid URI. I think if a relative path is given here (in Node.js) we should resolve it against the current directory.</p>
</li>
</ul> SaxonJS - Feature #4597 (New): Recognize entity declarations in DTDshttps://saxonica.plan.io/issues/45972020-06-17T11:28:24ZMichael Kaymike@saxonica.com
<p>We should recognise entity declarations in DTDs; at least to the extent that the XML parsers in browsers recognise them. This is typically limited to handling the internal DTD subset (probably with no external entity references; but the exact subset of XML that's accepted is unclear.)</p> W3C QT Specifications - Bug #4359 (New): Incorrect note regarding fn:collation-key()https://saxonica.plan.io/issues/43592019-10-24T08:57:58ZMichael Kaymike@saxonica.com
<p>In F&O 3.1, the notes for fn:collation-key() say:</p>
<blockquote>
<p>*This specification does not mandate that collation keys should retain ordering. This is partly because the primary use case is for maps, where only equality comparisons are required, and partly to allow the use of binary data types (which are currently unordered types) for the result. The specification may be revised in a future release to specify that ordering is preserved. *</p>
</blockquote>
<p>This paragraph is incorrect and should be deleted. The spec does now mandate that fn:collation-key() is order-preserving, and binary data types are now ordered, which was done specifically to make this possible.</p> W3C QT Specifications - Bug #4236 (New): Note regarding streamability of fn:filterhttps://saxonica.plan.io/issues/42362019-06-14T15:16:53ZMichael Kaymike@saxonica.com
<p>Section §19.8.9.10 discusses streamability of the fn:for-each function but the Note contains a reference to fn:filter, making it unclear whether this is a typo for fn:for-each. There's no separate section for streamability of fn:filter, which might be useful, even if the default rules say it all already.</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>