Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2024-03-27T11:18:36ZSaxonica Developer Community
Planio Saxon - Bug #6379 (New): Default implementation of fn:deep-equalhttps://saxonica.plan.io/issues/63792024-03-27T11:18:36ZNorm Tovey-Walsh
<p>I happened to trace my way through a call to deep equal in Saxon HE 12.4 and I was a little bit surprised to find that it's using the <code>DeepEqual40</code> implementation. I wonder if that was intentional...</p> Saxon - Support #6369 (New): Serialization problem of XQuery result using Saxon 12.3https://saxonica.plan.io/issues/63692024-03-06T10:36:34ZRadu Coravuradu_coravu@sync.ro
<p>We run this XQuery as a transformation scenario in Oxygen:</p>
<pre><code>declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
declare option output:method 'text';
declare option output:item-separator ', ';
let $xml:=<xml><element>text1</element><element>text2</element></xml> return $xml/element/string()
</code></pre>
<p>and we get as result:</p>
<pre><code>text1, , text2
</code></pre>
<p>Notice the two commas ", " between the two items.</p>
<p>To serialize we create a tree receiver something like:</p>
<pre><code> SerializerFactory sf = this.queryTransformer.getConfiguration().getSerializerFactory();
PipelineConfiguration pipe = this.queryTransformer.getConfiguration().makePipelineConfiguration();
SerializationProperties props = new SerializationProperties(queryTransformer.getOutputProperties());
Receiver receiver = sf.getReceiver(new StreamResult(sw), props, pipe);
tr = new TreeReceiver(receiver)..
</code></pre>
<p>The "net.sf.saxon.event.SequenceReceiver#decompose" is called for each item "text1" and "text2". The stack trace is something like:</p>
<pre><code> at net.sf.saxon.str.UnicodeWriterToWriter.write(UnicodeWriterToWriter.java:36)
at net.sf.saxon.serialize.TEXTEmitter.characters(TEXTEmitter.java:104)
at net.sf.saxon.event.ProxyReceiver.characters(ProxyReceiver.java:158)
at net.sf.saxon.event.SequenceNormalizer.characters(SequenceNormalizer.java:99)
at net.sf.saxon.event.SequenceNormalizerWithItemSeparator.sep(SequenceNormalizerWithItemSeparator.java:135)
at net.sf.saxon.event.SequenceNormalizerWithItemSeparator.characters(SequenceNormalizerWithItemSeparator.java:75)
at net.sf.saxon.event.TreeReceiver.characters(TreeReceiver.java:176)
at net.sf.saxon.event.SequenceReceiver.decompose(SequenceReceiver.java:178)
</code></pre>
<p>For "text2" which is ATOMIC the code in "net.sf.saxon.event.SequenceReceiver.decompose(Item, Location, int)" does this:</p>
<pre><code> protected void decompose(Item item, Location locationId, int copyNamespaces) throws XPathException {
if (item != null) {
switch (item.getGenre()) {
case ATOMIC:
case EXTERNAL:
if (previousAtomic) {
characters(StringConstants.SINGLE_SPACE, locationId, ReceiverOption.NONE);
}
characters(item.getUnicodeStringValue(), locationId, ReceiverOption.NONE);
</code></pre>
<p>It calls "characters(StringConstants.SINGLE_SPACE, locationId, ReceiverOption.NONE);" which adds a space and a comma before the space as the method "net.sf.saxon.event.SequenceNormalizerWithItemSeparator.characters(UnicodeString, Location, int)" always calls sep().
And then it calls:</p>
<pre><code>characters(item.getUnicodeStringValue(), locationId, ReceiverOption.NONE);
</code></pre>
<p>which again adds a comma before the value. So we get two commas before the actual value is printed.</p> Saxon - Bug #6343 (New): Function Coercion is not always appliedhttps://saxonica.plan.io/issues/63432024-02-11T23:27:14ZMichael Kaymike@saxonica.com
<p>I have created the following test case FunctionCall-058:</p>
<pre><code> declare function local:f($callback as function(xs:integer) as xs:boolean) as xs:boolean {
$callback(year-from-date(current-date()) div 1900)
};
local:f(function($d as xs:decimal) as xs:boolean { $d lt 0 })
</code></pre>
<p>This should fail because the <code>$callback</code> function requires an xs:integer but the supplied value (the result of the integer division) is an xs:decimal.</p>
<p>What is supposed to happen according to the spec is that the supplied function (which accepts an x:decimal) is coerced to the required type (which does not). The means that the function actually supplied to the $callback parameter is effectively:</p>
<pre><code>function($d1 as xs:integer) as xs:boolean {
function($d2 as xs:decimal) as xs:boolean { $d2 lt 0 } ($d1)
}
</code></pre>
<p>which should fail with a type error when called supplying an <code>xs:decimal</code>.</p>
<p>However, because the value supplied to the <code>$callback</code> parameter is an instance of the required type, Saxon skips the process of function coercion wrongly believing it to be unnecessary; his has the effect that the type error is not detected.</p> Saxon - Support #6322 (New): Is the old collation URI in EE supposed to rely on the JDK collation...https://saxonica.plan.io/issues/63222024-01-17T16:12:22ZMartin Honnenmartin.honnen@gmx.de
<p>I notice differences in collation dependent sorts whether I use the UCA URI or the legacy Saxon URI.</p>
<p>The documentation at <a href="https://www.saxonica.com/html/documentation12/localization/sorting-and-collations.html" class="external">https://www.saxonica.com/html/documentation12/localization/sorting-and-collations.html</a> says about collations</p>
<blockquote>
<p>For backwards compatibility reasons the standard collation resolver in Saxon also accepts URIs in the form <a href="http://saxon.sf.net/collation" class="external">http://saxon.sf.net/collation</a> followed by query parameters; the query parameters that are recognized are the same as those defined by W3C UCA collation URIs.</p>
</blockquote>
<p>It appears to me, however, that with EE, the use of the legacy collation URI means ICU is not used, only the default JDK collation support, as I get results similar to using HE.</p>
<p>Can anyone confirm that?</p>
<p>Details below:</p>
<p>An XQuery program using the UCA collation URI, run with Saxon 12.4 EE, gives the same result for all sorts, e.g. the following program outputs true:</p>
<pre><code>declare namespace array = "http://www.w3.org/2005/xpath-functions/array";
declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
declare option output:method 'text';
declare option output:item-separator '&#10;';
declare variable $strings as array(xs:string*) external := [
('abc', 'abc def', 'abcdef'),
('abc', 'abcdef', 'abc def'),
('abc def', 'abcdef', 'abc'),
('abc def', 'abc', 'abcdef'),
('abcdef', 'abc', 'abc def'),
('abcdef', 'abc def', 'abc')
];
let $sorted :=
array:for-each(
$strings,
function($seq) {
sort($seq, 'http://www.w3.org/2013/collation/UCA?strength=primary;lang=en')
})
return
every $pos in (1 to array:size($sorted))
satisfies
deep-equal($sorted($pos), $strings?1)
</code></pre>
<p>The same program using the legacy Saxon collation URI, however, gives different sort result, much like Saxon HE, e.g. the program outputs false:</p>
<pre><code>declare namespace array = "http://www.w3.org/2005/xpath-functions/array";
declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
declare option output:method 'text';
declare option output:item-separator '&#10;';
declare variable $strings as array(xs:string*) external := [
('abc', 'abc def', 'abcdef'),
('abc', 'abcdef', 'abc def'),
('abc def', 'abcdef', 'abc'),
('abc def', 'abc', 'abcdef'),
('abcdef', 'abc', 'abc def'),
('abcdef', 'abc def', 'abc')
];
let $sorted :=
array:for-each(
$strings,
function($seq) {
sort($seq, 'http://saxon.sf.net/collation?strength=primary;lang=en')
})
return
every $pos in (1 to array:size($sorted))
satisfies
deep-equal($sorted($pos), $strings?1)
</code></pre> Saxon - Bug #6307 (New): Saxon (HE; Java) trace missing xsl:accumulator and xsl:accumulator-rule,...https://saxonica.plan.io/issues/63072023-12-27T21:52:00ZA Galtman
<ul>
<li>Is the trace supposed to mark xsl:accumulator as hit?</li>
<li>Is the trace supposed to mark xsl:accumulator-rule as hit?</li>
<li>I definitely expect descendant elements of xsl:accumulator-rule to be marked as hit, and I'm not seeing them in Saxon 12.4. Saxon 9.9.1.8 correctly lists the descendants of xsl:accumulator-rule.</li>
</ul>
<p>I'm attaching a file that includes the code, the Saxon arguments I used, and the traces I got from Saxon 9.9.1.8 and 12.4.</p> Saxon - Bug #6305 (New): XPathException "The stylesheet module includes/imports itself directly o...https://saxonica.plan.io/issues/63052023-12-22T15:02:48ZGerben Abbinkgerben.abbink@gmail.com
<p>I use an ErrorReporter with XsltCompiler, like this:</p>
<pre><code>XsltCompiler compiler = processor.newXsltCompiler();
compiler.setErrorReporter(...);
</code></pre>
<p>Usually, XPathExceptions have a Location to identify the error in the file.</p>
<p>But, when I use this template, there is no location information:</p>
<pre><code><?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href=""/>
</xsl:stylesheet>
</code></pre> Saxon - Bug #6302 (New): Saxon (HE; Java) trace not well-formed when XSLT uses transform functionhttps://saxonica.plan.io/issues/63022023-12-21T19:56:45ZA Galtman
<p>(I alluded to this in my 12/21/23 comment in <a href="https://saxonica.plan.io/issues/6295" class="external">https://saxonica.plan.io/issues/6295</a> but it seems different enough that I'm making a separate issue for it rather than assume that the fix for 6295 is enough.)</p>
<p>The <code>transform()</code> function seems to cause the Saxon trace not to be well-formed.</p>
<a name="Sample-XSLT-1-transform-functionxsl"></a>
<h3 >Sample XSLT 1, transform-function.xsl<a href="#Sample-XSLT-1-transform-functionxsl" class="wiki-anchor">¶</a></h3>
<pre><code><?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:my="my-ns"
exclude-result-prefixes="#all"
version="3.0">
<xsl:template name="xsl:initial-template">
<xsl:variable name="transform-options" as="map(xs:string, item()*)">
<xsl:map>
<xsl:map-entry key="'delivery-format'" select="'raw'"/>
<xsl:map-entry key="'stylesheet-location'">target-stylesheet-small.xsl</xsl:map-entry>
<xsl:map-entry key="'function-params'" select="[()]"/>
<xsl:map-entry key="'initial-function'" select="QName('my-ns', 'my:fcn')"/>
</xsl:map>
</xsl:variable>
<xsl:sequence select="transform($transform-options)?output"/>
</xsl:template>
</xsl:stylesheet>
</code></pre>
<a name="Sample-XSLT-2-target-stylesheet-smallxsl"></a>
<h3 >Sample XSLT 2, target-stylesheet-small.xsl<a href="#Sample-XSLT-2-target-stylesheet-smallxsl" class="wiki-anchor">¶</a></h3>
<pre><code><?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fn="http://www.w3.org/2005/xpath-functions"
xmlns:my="my-ns"
exclude-result-prefixes="#all"
version="3.0">
<xsl:function name="my:fcn" visibility="public" as="xs:string">
<xsl:param name="p" as="empty-sequence()"/>
<xsl:sequence select="'output'"/>
</xsl:function>
</xsl:stylesheet>
</code></pre>
<a name="Saxon-command"></a>
<h3 >Saxon command<a href="#Saxon-command" class="wiki-anchor">¶</a></h3>
<pre><code>java -cp "%SAXON_CP%" net.sf.saxon.Transform -opt:0 -T -Tlevel:high -it -xsl:transform-function.xsl 2>transform-function-traceresult.xml
</code></pre>
<p>I'm using Saxon-HE 12.4.</p>
<a name="Trace-Result"></a>
<h3 >Trace Result<a href="#Trace-Result" class="wiki-anchor">¶</a></h3>
<pre><code><trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="xsl:initial-template" line="9" column="45" module="transform-function.xsl">
<xsl:variable name="transform-options" line="10" column="73" module="transform-function.xsl">
<trace text="target-stylesheet-small.xsl" line="13" column="52" module="transform-function.xsl">
</trace>
<trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:function arity="1" name="my:fcn" line="9" column="66" module="target-stylesheet-small.xsl">
</xsl:function>
</xsl:variable>
</xsl:template>
</trace>
</code></pre> Saxon - Bug #6263 (New): Test case try-031 fails under Saxon-HE (try/catch with lazy evaluation)https://saxonica.plan.io/issues/62632023-11-28T11:01:55ZMichael Kaymike@saxonica.com
<p>The XSLT 3.0 test case try-031 is failing under Saxon-HE. The essence of the failure is that in the construct</p>
<pre><code><xsl:variable name="p" select="...."/>
<xsl:try>
<xsl:value-of select="$p"/>
<xsl:catch>
<caught/>
</xsl:catch>
</xsl:try>
</code></pre>
<p>an error occurring during lazy evaluation of $p is caught by the try/catch when it should not be.</p>
<p>The test is failing in the candidate 12.4 release but also fails in earlier releases.</p> Saxon - Feature #6240 (New): Include custom error feedback when using .NET XmlResolverhttps://saxonica.plan.io/issues/62402023-11-06T13:56:33ZEmanuel Wlaschitzemanuel.wlaschitz@hico.com
<p>This is a follow-up to <a class="issue tracker-1 status-3 priority-1 priority-lowest closed" title="Bug: Cannot use InputXmlResolver to implement custom scheme on Saxon-HE 10N (Closed)" href="https://saxonica.plan.io/issues/6214">#6214</a> to get better error feedback to our end-users.</p>
<p>Using a simplified <code>XmlResolver</code>:</p>
<pre><code class="c# syntaxhl" data-language="c#"> <span class="k">sealed</span> <span class="k">class</span> <span class="nc">CustomResolver</span> <span class="p">:</span> <span class="n">XmlResolver</span>
<span class="p">{</span>
<span class="k">private</span> <span class="k">readonly</span> <span class="n">XmlResolver</span> <span class="n">_innerResolver</span><span class="p">;</span>
<span class="k">public</span> <span class="nf">CustomResolver</span><span class="p">(</span><span class="n">XmlResolver</span> <span class="n">innerResolver</span><span class="p">)</span> <span class="p">=></span> <span class="n">_innerResolver</span> <span class="p">=</span> <span class="n">innerResolver</span><span class="p">;</span>
<span class="k">public</span> <span class="k">override</span> <span class="n">ICredentials</span> <span class="n">Credentials</span> <span class="p">{</span> <span class="k">set</span> <span class="p">{</span> <span class="n">_innerResolver</span><span class="p">.</span><span class="n">Credentials</span> <span class="p">=</span> <span class="k">value</span><span class="p">;</span> <span class="p">}</span> <span class="p">}</span>
<span class="k">public</span> <span class="k">override</span> <span class="n">Uri</span> <span class="nf">ResolveUri</span><span class="p">(</span><span class="n">Uri</span> <span class="n">baseUri</span><span class="p">,</span> <span class="kt">string</span> <span class="n">relativeUri</span><span class="p">)</span> <span class="p">=></span> <span class="k">base</span><span class="p">.</span><span class="nf">ResolveUri</span><span class="p">(</span><span class="n">baseUri</span><span class="p">,</span> <span class="n">relativeUri</span><span class="p">);</span>
<span class="k">public</span> <span class="k">override</span> <span class="kt">object</span> <span class="nf">GetEntity</span><span class="p">(</span><span class="n">Uri</span> <span class="n">absoluteUri</span><span class="p">,</span> <span class="kt">string</span> <span class="n">role</span><span class="p">,</span> <span class="n">Type</span> <span class="n">ofObjectToReturn</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">throw</span> <span class="k">new</span> <span class="nf">Exception</span><span class="p">(</span><span class="s">$"The custom url </span><span class="p">{</span><span class="n">absoluteUri</span><span class="p">}</span><span class="s"> is not available. Use doc-available() to test for this before using document()"</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre>
<p>...and a minimal transformation:</p>
<pre><code class="c# syntaxhl" data-language="c#"><span class="kt">var</span> <span class="n">xsltTransformer</span> <span class="p">=</span> <span class="nf">CompileTestStylesheet</span><span class="p">();</span>
<span class="n">xsltTransformer</span><span class="p">.</span><span class="n">InputXmlResolver</span> <span class="p">=</span> <span class="k">new</span> <span class="nf">CustomResolver</span><span class="p">(</span><span class="n">xsltTransformer</span><span class="p">.</span><span class="n">InputXmlResolver</span><span class="p">);</span>
<span class="k">try</span>
<span class="p">{</span>
<span class="kt">var</span> <span class="n">output</span> <span class="p">=</span> <span class="k">new</span> <span class="nf">XDocument</span><span class="p">();</span>
<span class="k">using</span> <span class="p">(</span><span class="kt">var</span> <span class="n">outputWriter</span> <span class="p">=</span> <span class="n">output</span><span class="p">.</span><span class="nf">CreateWriter</span><span class="p">())</span>
<span class="p">{</span>
<span class="kt">var</span> <span class="n">destination</span> <span class="p">=</span> <span class="k">new</span> <span class="nf">TextWriterDestination</span><span class="p">(</span><span class="n">outputWriter</span><span class="p">)</span> <span class="p">{</span> <span class="n">CloseAfterUse</span> <span class="p">=</span> <span class="k">true</span> <span class="p">};</span>
<span class="n">xsltTransformer</span><span class="p">.</span><span class="nf">Run</span><span class="p">(</span><span class="n">destination</span><span class="p">);</span>
<span class="p">}</span>
<span class="n">Console</span><span class="p">.</span><span class="nf">WriteLine</span><span class="p">(</span><span class="n">output</span><span class="p">);</span>
<span class="p">}</span>
<span class="k">catch</span> <span class="p">(</span><span class="n">DynamicError</span> <span class="n">ex</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">Console</span><span class="p">.</span><span class="nf">WriteLine</span><span class="p">(</span><span class="s">"DYNAMIC ERROR"</span><span class="p">);</span>
<span class="n">Console</span><span class="p">.</span><span class="nf">WriteLine</span><span class="p">(</span><span class="n">ex</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
<p>...which is basically:</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="nt"><xsl:stylesheet</span> <span class="na">xmlns:xsl=</span><span class="s">"http://www.w3.org/1999/XSL/Transform"</span> <span class="na">version=</span><span class="s">"3.0"</span><span class="nt">></span>
<span class="nt"><xsl:template</span> <span class="na">match=</span><span class="s">"/"</span><span class="nt">></span>
<span class="nt"><root></span>
<span class="nt"><xsl:sequence</span> <span class="na">select=</span><span class="s">"document('custom-scheme://test')"</span><span class="nt">/></span>
<span class="nt"></root></span>
<span class="nt"></xsl:template></span>
<span class="nt"></xsl:stylesheet></span>
</code></pre>
<p>...yields the following console output:</p>
<pre><code>Error at char 9 in expression in xsl:sequence/@select on line 4 column 61 of xslt-custom-uri-scheme-test1.xsl:
FODC0002 Exception thrown by URIResolver resolving `custom-scheme://test` against
`file:///D:/_dev/Saxon10CustomResolverTest1/bin/Debug/xslt-custom-uri-scheme-test1.xsl'.
Caused by net.sf.saxon.trans.XPathException: The custom url custom-scheme://test/ is not
available. Use doc-available() to test for this before using document(). Caused by
cli.System.Exception: The custom url custom-scheme://test/ is not available. Use
doc-available() to test for this before using document()
In template rule with match="/" on line 2 of xslt-custom-uri-scheme-test1.xsl
DYNAMIC ERROR
Exception thrown by URIResolver resolving `custom-scheme://test` against `file:///D:/_dev/Saxon10CustomResolverTest1/bin/Debug/xslt-custom-uri-scheme-test1.xsl'
</code></pre>
<p>The top part is from the internal console writer thats attached by default (...where I'm wondering: Can we redirect this? It sometimes contains additional information that isn't part of a thrown <code>StaticError</code>, <code>DynamicError</code> and isn't passed into the set <code>ErrorList</code> but would be useful to either the end user themselves or at least us as developers) while the bottom part is from catching the <code>DynamicError</code>.</p>
<p>Note that the top part includes the custom exception message, but the bottom part doesn't.</p>
<p>It would be nice if the thrown <code>DynamicError</code> could include the actual exception message <em>somewhere</em> (preferably as <code>InnerException</code> in .NET; not sure if Java would want to use the same approach.) Right now there is no way of getting this info through normal means; the only workaround we could identify was to pass <em>something</em> (like the <code>IMessageListener2</code> we attach anyways) into the <code>CustomResolver</code> and directly call methods on it.</p>
<p>I could only test this against Saxon 10, since there are no HE versions of 11/12 yet (nor do I have a license for it at this point.)</p> Saxon - Bug #6191 (New): Released SaxonCS artefact is a debug buildhttps://saxonica.plan.io/issues/61912023-09-01T15:54:06ZMichael Kaymike@saxonica.com
<p>Email from Nick Trevor:</p>
<p>Sorry to reach out directly, but was wondering if you could help. I'm test the performance of SaxonCS and when running the benchmarks I am getting warned that the nuget package is a debug build which could impact performance. Is it possible to get a release package published to nuget?</p>
<pre><code>// * Assembly Benchmarks which defines benchmarks references non-optimized SaxonCS
If you own this dependency, please, build it in RELEASE.
If you don't, you can disable this policy by using 'config.WithOptions(ConfigOptions.DisableOptimizationsValidator)'
</code></pre> Saxon - Bug #6172 (New): In 4.0, keywords in function calls are sometimes ignoredhttps://saxonica.plan.io/issues/61722023-08-15T22:10:05ZMichael Kaymike@saxonica.com
<p>XPath 4.0 allows function calls to provide argument values by keyword as well as positionally.</p>
<p>Some function libraries simply ignore any supplied keywords and interpret all arguments as positional. These include:</p>
<ul>
<li>constructor functions</li>
<li>Java extension functions (both reflexive and integrated)</li>
<li>The xsl:original pseudo-function</li>
<li>Some libraries implemented as Java extension functions,</li>
</ul>
<p>Some function libraries such as EXPath File and Binary are implemented as BuiltInFunctionSets, so keywords should work in principle, but no keyword data has been created, so using keywords will likely fail in unpredictable ways. It's not actually clear what we should do here: should we implement the parameter keywords defined in the spec, even though they were never intended to be used in this way?</p> Saxon - Bug #6127 (New): Documentation: argument keywords in function libraryhttps://saxonica.plan.io/issues/61272023-07-10T07:56:11ZMichael Kaymike@saxonica.com
<p>The documentation of the function library has not kept up to date with changes in argument keywords in the 4.0 specification. For example</p>
<p><a href="https://www.saxonica.com/documentation12/index.html#!functions/fn/reverse" class="external">https://www.saxonica.com/documentation12/index.html#!functions/fn/reverse</a></p>
<p>lists the signature as</p>
<pre><code>reverse($arg as item()*) ➔ item()*
</code></pre>
<p>but the argument keyword has changed from <code>arg</code> to <code>input</code>. The argument keywords are relevant in 4.0 because arguments can be identified by name in a function call.</p> Saxon - Support #6072 (New): SaxonCS used package ICU4N.Resources 60.1.0-alpha.402 generates warn...https://saxonica.plan.io/issues/60722023-06-11T16:06:11ZMartin Honnenmartin.honnen@gmx.de
<p>The SaxonCS (12.2) package uses a package ICU4N.Resources 60.1.0-alpha.402 that for me generates lots of warnings in the form of</p>
<pre><code>1>C:\Program Files\dotnet\sdk\7.0.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): warning NETSDK1187: Das Paket ICU4N.Resources 60.1.0-alpha.402 verfügt über eine Ressource mit dem gebietsschema-'bm-ML'. Dieses Gebietsschema wurde auf das Standardformat 'bm-Latn-ML' normalisiert, um Groß-/Kleinschreibungsprobleme im Build zu vermeiden. Erwägen Sie, den Paketautor über dieses Groß-/Kleinschreibungsproblem zu benachrichtigen.
</code></pre>
<p>basically saying that the region schema name of a used resource has been normalized/standardized and the package author of ICUN should be informed about that change in using lower case/upper case.</p>
<p>Perhaps if there is already a fix to ICU4N you can make sure that next maintenance release of SaxonCS includes that.</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> 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>