Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2020-09-14T15:03:14ZSaxonica Developer Community
Planio 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> 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> 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> 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> SaxonC - Support #1962 (New): Saxon/C and pkg-confighttps://saxonica.plan.io/issues/19622013-12-16T10:41:57ZO'Neil Delprattoneil@saxonica.com
<p>Reported by Tony Graham:</p>
<blockquote>
<p>From the 'pkg-config' page at [1]:</p>
</blockquote>
<p>pkg-config is a helper tool used when compiling applications</p>
<p>and libraries.</p>
<p>See also "Guide to pkg-config" at [2].</p>
<p>If Saxon/C is to play nicely with other Linux, etc., packages, you may</p>
<p>want to look at producing a 'pkg-config' file to make it easier for people</p>
<p>building the other packages -- particularly but not limited to people</p>
<p>building using Autotools -- to find how to refer to Saxon/C when compiling</p>
<p>and linking.</p>
<p>Here's what I've been faking as 'saxon-c.pc':</p>
<hr>
<pre><code>prefix=/usr/local/src/saxon-c/Saxonica/Saxon-HEC0.1
exec_prefix=${prefix}
libdir=${exec_prefix}
pkgincludedir=${prefix}/Saxon-C-API
Name: Saxon/C
Description: Saxon/C
Version: 0.1
Libs: -L${libdir} -lsaxon
Cflags: -I${pkgincludedir} -I/usr/lib/jvm/java-6-openjdk-amd64/include
</code></pre>
<hr>
<p>and here's what I've put in 'configure.ac' for xmlroff:</p>
<hr>
<pre><code>#
# Checks for Saxon/C
#
SAXON_C_PACKAGES=saxon-c
SAXON_C_REQUIRED_VERSION=0.1
AH_TEMPLATE([ENABLE_SAXON_C],
[Enable support for Saxon/C XSLT 2.0 processor.])
AC_ARG_ENABLE(saxon_c,
AC_HELP_STRING([--enable-saxon-c],
[build Saxon/C XSLT processor capability (default=yes)]),
enable_saxon_c_arg="$enableval",
enable_saxon_c_arg=yes)
if test "x$enable_saxon_c_arg" != "xyes" ; then
enable_saxon_c_arg=no
fi
enable_saxon_c=false
SAXON_C_REQUIRES=""
have_saxon_c=false
if test "x$enable_saxon_c_arg" = "xyes" ; then
#
# Check for Saxon/C support requirement
#
have_saxon_c=false
PKG_CHECK_MODULES(SAXON_C,
$SAXON_C_PACKAGES >= $SAXON_C_REQUIRED_VERSION,
have_saxon_c=true,
if $have_saxon_c; then
enable_saxon_c=true
AC_DEFINE(ENABLE_SAXON_C,1)
else
AC_DEFINE(ENABLE_SAXON_C,0)
SAXON_C_LIBS=""
SAXON_C_CFLAGS=""
fi
fi
AC_SUBST(SAXON_C_ENABLED, [$enable_saxon_c])
AC_SUBST(SAXON_C_REQUIRES)
AC_SUBST(SAXON_C_LIBS)
AC_SUBST(SAXON_C_CFLAGS)
AC_SUBST(ENABLE_SAXON_C, [$enable_saxon_c])
AM_CONDITIONAL(ENABLE_SAXON_C, [$enable_saxon_c])
</code></pre>
<hr>
<p>Tony Graham <a href="mailto:tgraham@mentea.net" class="email">tgraham@mentea.net</a></p>
<p>Consultant <a href="http://www.mentea.net" class="external">http://www.mentea.net</a></p>
<p>Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland</p>
<hr>
<pre><code>XML, XSL-FO and XSLT consulting, training and programming
Chair, Print and Page Layout Community Group @ W3C
</code></pre>
<p>[1] <a href="http://www.freedesktop.org/wiki/Software/pkg-config/" class="external">http://www.freedesktop.org/wiki/Software/pkg-config/</a></p>
<p>[2] <a href="http://people.freedesktop.org/~dbn/pkg-config-guide.html" class="external">http://people.freedesktop.org/~dbn/pkg-config-guide.html</a></p>