Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2021-02-18T17:57:50ZSaxonica Developer Community
Planio 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 #4829 (New): Static variable initialised to node values cause run-time failurehttps://saxonica.plan.io/issues/48292020-11-18T14:10:54ZJohn Lumleyjohn@saxonica.com
<p>When compiling with the XJ compiler a static variable initialised to a node such as:</p>
<pre><code><xsl:variable name="t" static="yes" select="doc('testStatic.xml')"/>
</code></pre>
<p>where <code>testStatic.xml</code> is:</p>
<pre><code><foo a="1" xmlns:b="BBB" b:attribute="" xmlns="Flibbertygibbet">
<bar/>
</foo>
</code></pre>
<p>the generated package contains a component definition:</p>
<pre><code><co id='0' binds=''>
<globalVariable name='Q{}t' as='1ND' line='7' .... visibility='PRIVATE' flags='s'>
<node kind='9' content='&lt;foo xmlns="Flibbertygibbet" xmlns:b="BBB" a="1" b:attribute=""&gt;&#xA; &lt;bar/&gt;&#xA;&lt;/foo&gt;' baseUri='....testStatic.xml'/>
</globalVariable>
</co>
</code></pre>
<p>that is the serialization of the document is held as the <code>content</code> property of a <code>node</code> instruction, with the <code>kind</code> of the node indicated.</p>
<p>If the selection is <code>doc('testStatic.xml')/(*,*/@*)</code> the compilation becomes:</p>
<pre><code><globalVariable name='Q{}t' as='*N' line='7' ....visibility='PRIVATE' flags='s'>
<literal count='3'>
<node kind='1' content='&lt;foo xmlns="Flibbertygibbet" xmlns:b="BBB" a="1" b:attribute=""&gt;&#xA; &lt;bar/&gt;&#xA;&lt;/foo&gt;' baseUri='..../testStatic.xml'/>
<node kind='2' localName='a' content='1'/>
<node kind='2' localName='attribute' prefix='b' ns='BBB' content=''/>
</literal>
</globalVariable>
</code></pre>
<p>Execution of a reference to this variable in <code>SaxonJS2</code> throws an error as there is currently no support for a <code>node</code> instruction.</p>
<p>There appear to be two routes to solution:</p>
<ol>
<li>Converting the export to a nested set of aleady supported node construction instructions <code>elem</code>, <code>att</code>, <code>text</code> etc, which will be very costly and increase the export size considerably.</li>
<li>Add support for a <code>node</code> instruction, using the implementation code for <code>parse-xml()</code> when necessary</li>
</ol>
<p>The latter seems much more sensible.</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> SaxonC - Bug #4665 (New): Limitation of command-line options not indicated in documentationhttps://saxonica.plan.io/issues/46652020-08-03T10:57:32ZO'Neil Delprattoneil@saxonica.com
<p>There general statement mentioned in the section about <a href="http://www.saxonica.com/saxon-c/documentation/index.html#!starting/running" class="external">command-line interface</a>: “The same command line options as in the Java products are available in the Saxon/C command line tool. Please see the relevant sections of the Saxon 9.9 documentation for details:”</p>
<p>Perhaps it could go in the Limitations section here? <a href="http://www.saxonica.com/saxon-c/documentation/index.html#!technical" class="external">http://www.saxonica.com/saxon-c/documentation/index.html#!technical</a></p> SaxonC - Bug #4609 (New): Lack of documentation to package Saxon/C C++ in third-party systemshttps://saxonica.plan.io/issues/46092020-06-22T12:00:52ZO'Neil Delprattoneil@saxonica.com
<p>This bug is created as a result of a user enquiry.</p>
<p>There seems to be a lack of documentation on how to package Saxon/C C++ API in a third-party system. There needs to be a clear guide to say what needs building in advance to create the required executable files for another system within the C++ environment (i.e. modules/dlls/components for Saxon/C runtime?)</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> SaxonC - Bug #4477 (New): Extension function code should be removed Saxon-HE/Chttps://saxonica.plan.io/issues/44772020-03-10T11:48:56ZO'Neil Delprattoneil@saxonica.com
<p>As a result of the following stackover flow question:
<a href="https://stackoverflow.com/questions/60613404/saxon-c-centos8-compile" class="external">saxon-c-centos8-compile</a></p>
<p>It is clear the Saxon-He/C code base should not have code for the extension function feature.
Should only be available in Saxon-PE/C and Saxon-EE/C.</p>
<p>Also when the compile flag <code>-Werror=sizeof-pointer-div</code> is used we get the following error:</p>
<pre><code>../../Saxon.C.API/SaxonProcessor.h:599:32: error: division ‘sizeof (JNINativeMethod*) / sizeof (JNINativeMethod)’
does not compute the number of array
elements [-Werror=sizeof-pointer-div] gMethods, sizeof(gMethods) / sizeof(gMethods[0]));
</code></pre> 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> SaxonC - Bug #4312 (New): XDM_NODE_KIND enumeration type not available in PHPhttps://saxonica.plan.io/issues/43122019-09-13T10:08:25ZO'Neil Delprattoneil@saxonica.com
<p>It would be good to have XDM_NODE_KIND enumeration type available in the Saxon/C PHP extension.</p>
<p>This would be similar to what we have in the C++ API.</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> Non-Conformances - Bug #4220 (New): Exposed visibility of xsl:paramhttps://saxonica.plan.io/issues/42202019-05-15T10:39:14ZMichael Kaymike@saxonica.com
<p>Unit test <code>s9apitests/TestPackage/testPackageRenamingExported</code> is failing with an error saying it cannot accept xsl:param elements with private visibility as hidden.</p>
<p>The spec says (a) that xsl:param elements are always public, and (b) that their visibility cannot be changed by <code>xsl:expose</code> or <code>xsl:accept</code>.</p>
<p>What this test is trying to do is to compile a single package three times with different settings of a static parameter, and then import all three exported packages into a single top-level package (using package aliases to achieve this). It might be that we won't be able to get this to work, but we need to investigate why it's failing the way that it is. The spec says that xsl:param is public, but we're reporting it as private.</p> SaxonC - Bug #3726 (New): Saxon License not being picked up relative to library filehttps://saxonica.plan.io/issues/37262018-03-26T15:48:57ZO'Neil Delprattoneil@saxonica.com
<p>According to the documentation:</p>
<p><a href="http://saxonica.com/saxon-c/index.xml#license" class="external">http://saxonica.com/saxon-c/index.xml#license</a></p>
<pre><code>Location of the Saxon license file for commercial products: Saxon/C looks in the path relative to where the main library has been installed. For example, in '/usr/lib', if this is where libsaxon[EDITION]c.so has been installed. Alternatively, Saxon also looks for the license according to the environment variable SAXONC_HOME, if this has been set.
</code></pre>
<p>After inspecting the code it seems to me that the license Verify class does not look in the directory relative to the main library. Therefore the license file can only be picked up either by the setting of the SAXONC_HOME environment variable or by placing the license file relative to the XSLT stylesheet.</p> Non-Conformances - Bug #3531 (New): Substitution groups are not mergedhttps://saxonica.plan.io/issues/35312017-11-16T07:07:38ZMichael Kaymike@saxonica.com
<p>Taking this over as a sub-problem of bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: --multipleSchemaImports has no effect when processing a cycle of schema documents (Closed)" href="https://saxonica.plan.io/issues/3202">#3202</a>.</p>
<p>MHK IntelliJ project Saxon9.8/XBRLTest</p>
<p>When there are several independent calls on SchemaManager.load(), each call on load() results in a new PreparedSchema being built; and if the schema is then found to be valid, its components are merged into the global schema for the Configuration. (We carefully avoid making any changes to the global schema until the new local schema has been verified as being valid.)</p>
<p>If two of these calls on load() specify two different schemas which both import some common schema, it's possible that either or both may declare elements to be in the substitution group of some element declaration in the common schema. When this happens then the process of merging the local schema into the global schema should form the union of the two substitution groups (and in turn, this should trigger recompilation of any affected types). This is not happening: we use one element declaration or the other, but we never merge them in this way.</p>
<p>The logic is complicated by xs:redefine, but let's focus on getting it right in the absence of xs:redefine.</p>