Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2020-10-30T10:05:35ZSaxonica Developer Community
Planio 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> Saxon - Bug #4664 (In Progress): Xerces bug: Wrong value of xml:base attribute after resolving XI...https://saxonica.plan.io/issues/46642020-08-03T10:48:44ZO'Neil Delprattoneil@saxonica.com
<p>The following Xerces bug is affecting several users: <a href="https://issues.apache.org/jira/browse/XERCESJ-1102" class="external">https://issues.apache.org/jira/browse/XERCESJ-1102</a></p>
<p>This bug causes the wrong value of xml:base attribute after resolving XInclude references. One user applies a the patch in a jar file that is included on the Java classpath when Saxon is invoked. It would be good to apply this patch internally with Saxon as part of the issued product.</p>
<p>This affects: Saxon-J, Saxon.NET and Saxon/C</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 #4178 (In Progress): License file not found with symbolic linkshttps://saxonica.plan.io/issues/41782019-03-25T10:48:28ZO'Neil Delprattoneil@saxonica.com
<p>Reported by user:</p>
<p>There's a bit of inconsistency over how co-locating the licence file and libsaxoneec.so works when used with softlinks.</p>
<p>Soft linking libraries is pretty typical in /usr/lib so I think Saxon should support this.</p>
<p>If I have the below setup in /usr/lib it doesn't work:</p>
<p>lrwxrwxrwx 1 root root 43 Mar 21 22:27 /usr/lib/libsaxoneec.so -> /opt/Saxonica/Saxon-EEC1.1.2/libsaxoneec.so<br>
lrwxrwxrwx 1 root root 31 Oct 16 14:53 /usr/lib/saxon-license.lic -> /opt/Saxonica/saxon-license.lic</p>
<p>Guessing that the softlink for libsaxoneec.so is resolved to it's real path I tried putting saxon-licence.lic in the same directory, but it doesn't work either:</p>
<p>/opt/Saxonica/Saxon-EEC1.1.2/</p>
<p>Some sort of resolving required.</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>