Saxonica Developer Community: Issueshttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2023-05-21T17:29:54ZSaxonica Developer Community
Planio Saxon - Bug #6042 (AwaitingInfo): Xerces occasionally throws ArrayIndexOutOfBoundsExceptionhttps://saxonica.plan.io/issues/60422023-05-21T17:29:54ZNorm Tovey-Walsh
<p>Can't reproduce this locally and debugging through the narrow opening provided by CI is awfully painful, but FYI:</p>
<p>This is <code>xspec.bat</code> (slightly hacked) from the DocBook xslTNG project running on Windows CI in GitHub. I've instrumented the batch file with:</p>
<pre><code> echo "XSLT:"
echo %*
</code></pre>
<p>The full command is:</p>
<pre><code> java ^
-Dfile.encoding=UTF-8 ^
-Dxspec.coverage.ignore="%TEST_DIR%" ^
-Dxspec.coverage.xml="%COVERAGE_XML%" ^
-Dxspec.home="%XSPEC_HOME%" ^
-Dxspec.xspecfile="%XSPEC%" ^
-Dorg.docbook.xsltng.extensions.pygmentize="%PYGMENTIZE%" ^
-Dorg.docbook.xsltng.verbose="%VERBOSE%" ^
-cp "%CP%" net.sf.saxon.Transform %CATALOG% ^
-init:org.docbook.xsltng.extensions.Register %*
</code></pre>
<p>With Saxon 11.5:</p>
<pre><code>Formatting Report...
"XSLT:"
-o:"D:\a\xslTNG\xslTNG\build\default-result.html" -s:"D:\a\xslTNG\xslTNG\build\default-result.xml" -xsl:"D:\a\xslTNG\xslTNG\build\xspec-2.2.4\bin\..\src\reporter\format-xspec-report.xsl" inline-css=true
java.lang.IllegalStateException: java.lang.ArrayIndexOutOfBoundsException: 2048
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:233)
at net.sf.saxon.resource.ActiveStreamSource.deliver(ActiveStreamSource.java:65)
at net.sf.saxon.event.Sender.send(Sender.java:105)
at net.sf.saxon.Configuration.buildDocumentTree(Configuration.java:4138)
at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:334)
at net.sf.saxon.Transform.processFile(Transform.java:1346)
at net.sf.saxon.Transform.doTransform(Transform.java:871)
at net.sf.saxon.Transform.main(Transform.java:81)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048
at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.scanContent(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:190)
... 7 more
Fatal error during transformation: java.lang.IllegalStateException: java.lang.ArrayIndexOutOfBoundsException: 2048
*** Error formatting the report
</code></pre>
<p>with Saxon 12.2:</p>
<pre><code>Formatting Report...
"XSLT:"
-o:"D:\a\xslTNG\xslTNG\build\default-result.html" -s:"D:\a\xslTNG\xslTNG\build\default-result.xml" -xsl:"D:\a\xslTNG\xslTNG\build\xspec-2.2.4\bin\..\src\reporter\format-xspec-report.xsl" inline-css=true
java.lang.ArrayIndexOutOfBoundsException: 2048
at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.scanContent(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:190)
at net.sf.saxon.resource.ActiveStreamSource.deliver(ActiveStreamSource.java:65)
at net.sf.saxon.event.Sender.send(Sender.java:104)
at net.sf.saxon.Configuration.buildDocumentTree(Configuration.java:4210)
at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:334)
at net.sf.saxon.Transform.processFile(Transform.java:1345)
at net.sf.saxon.Transform.doTransform(Transform.java:879)
at net.sf.saxon.Transform.main(Transform.java:83)
Fatal error during transformation: java.lang.ArrayIndexOutOfBoundsException: 2048
*** Error formatting the report
</code></pre>
<p>It's particularly annoying that this looks like an encoding issue but I have explicitly specified the <code>file.encoding</code> and the same code on my local Windows machine does not fail.</p> Saxon - Support #5980 (New): Should setting parser property affect XsltCompiler?https://saxonica.plan.io/issues/59802023-04-19T13:28:21ZMartin Honnenmartin.honnen@gmx.de
<p>Using Saxon 12.1 HE, the code</p>
<pre><code class="java syntaxhl" data-language="java"> <span class="nc">Processor</span> <span class="n">processor</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">Processor</span><span class="o">(</span><span class="kc">false</span><span class="o">);</span>
<span class="nc">Configuration</span> <span class="n">configuration</span> <span class="o">=</span> <span class="n">processor</span><span class="o">.</span><span class="na">getUnderlyingConfiguration</span><span class="o">();</span>
<span class="n">configuration</span><span class="o">.</span><span class="na">setParseOptions</span><span class="o">(</span><span class="n">configuration</span><span class="o">.</span><span class="na">getParseOptions</span><span class="o">().</span><span class="na">withParserProperty</span><span class="o">(</span><span class="s">"http://www.oracle.com/xml/jaxp/properties/"</span> <span class="o">+</span> <span class="s">"entityExpansionLimit"</span><span class="o">,</span> <span class="s">"128000"</span><span class="o">));</span>
<span class="nc">XsltCompiler</span> <span class="n">xsltCompiler</span> <span class="o">=</span> <span class="n">processor</span><span class="o">.</span><span class="na">newXsltCompiler</span><span class="o">();</span>
<span class="nc">XsltExecutable</span> <span class="n">xsltExecutable</span> <span class="o">=</span> <span class="n">xsltCompiler</span><span class="o">.</span><span class="na">compile</span><span class="o">(</span><span class="k">new</span> <span class="nc">File</span><span class="o">(</span><span class="s">"C:\\Users\\marti\\Downloads\\entity-expansion-size.xsl"</span><span class="o">));</span>
<span class="nc">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="n">xsltExecutable</span><span class="o">);</span>
</code></pre>
<p>with the XSLT from <a href="https://saxonica.plan.io/attachments/64064" class="external">https://saxonica.plan.io/attachments/64064</a> gives an exception indicating that the parser property I have set is not taken into account by the parser XsltCompiler uses:</p>
<pre><code>Error on line 1 column 1
SXXP0003 Error reported by XML parser: JAXP00010001: Der Parser hat mehr als 64000
Entityerweiterungen in diesem Dokument gefunden. Dies ist der von JDK vorgeschriebene
Grenzwert.: JAXP00010001: Der Parser hat mehr als 64000 Entityerweiterungen in diesem
Dokument gefunden. Dies ist der von JDK vorgeschriebene Grenzwert.
Exception in thread "main" net.sf.saxon.s9api.SaxonApiException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; JAXP00010001: Der Parser hat mehr als 64000 Entityerweiterungen in diesem Dokument gefunden. Dies ist der von JDK vorgeschriebene Grenzwert.
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:974)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:996)
at org.example.Main2.main(Main2.java:17)
Caused by: net.sf.saxon.trans.XPathException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; JAXP00010001: Der Parser hat mehr als 64000 Entityerweiterungen in diesem Dokument gefunden. Dies ist der von JDK vorgeschriebene Grenzwert.
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:224)
at net.sf.saxon.resource.ActiveStreamSource.deliver(ActiveStreamSource.java:65)
at net.sf.saxon.event.Sender.send(Sender.java:104)
at net.sf.saxon.style.StylesheetModule.sendStylesheetSource(StylesheetModule.java:157)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:231)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:113)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:969)
... 2 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; JAXP00010001: Der Parser hat mehr als 64000 Entityerweiterungen in diesem Dokument gefunden. Dies ist der von JDK vorgeschriebene Grenzwert.
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1408)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1332)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(XMLDocumentFragmentScannerImpl.java:1844)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2985)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:190)
... 8 more
</code></pre>
<p>When I change the code to use a DocumentBuilder e.g.</p>
<pre><code class="java syntaxhl" data-language="java"> <span class="nc">Processor</span> <span class="n">processor</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">Processor</span><span class="o">(</span><span class="kc">false</span><span class="o">);</span>
<span class="nc">Configuration</span> <span class="n">configuration</span> <span class="o">=</span> <span class="n">processor</span><span class="o">.</span><span class="na">getUnderlyingConfiguration</span><span class="o">();</span>
<span class="n">configuration</span><span class="o">.</span><span class="na">setParseOptions</span><span class="o">(</span><span class="n">configuration</span><span class="o">.</span><span class="na">getParseOptions</span><span class="o">().</span><span class="na">withParserProperty</span><span class="o">(</span><span class="s">"http://www.oracle.com/xml/jaxp/properties/"</span> <span class="o">+</span> <span class="s">"entityExpansionLimit"</span><span class="o">,</span> <span class="s">"128000"</span><span class="o">));</span>
<span class="nc">DocumentBuilder</span> <span class="n">docBuilder</span> <span class="o">=</span> <span class="n">processor</span><span class="o">.</span><span class="na">newDocumentBuilder</span><span class="o">();</span>
<span class="nc">XdmNode</span> <span class="n">doc</span> <span class="o">=</span> <span class="n">docBuilder</span><span class="o">.</span><span class="na">build</span><span class="o">(</span><span class="k">new</span> <span class="nc">File</span><span class="o">(</span><span class="s">"C:\\Users\\marti\\Downloads\\entity-expansion-size.xsl"</span><span class="o">));</span>
<span class="nc">XsltCompiler</span> <span class="n">xsltCompiler</span> <span class="o">=</span> <span class="n">processor</span><span class="o">.</span><span class="na">newXsltCompiler</span><span class="o">();</span>
<span class="nc">XsltExecutable</span> <span class="n">xsltExecutable</span> <span class="o">=</span> <span class="n">xsltCompiler</span><span class="o">.</span><span class="na">compile</span><span class="o">(</span><span class="n">doc</span><span class="o">.</span><span class="na">asSource</span><span class="o">());</span>
<span class="nc">System</span><span class="o">.</span><span class="na">out</span><span class="o">.</span><span class="na">println</span><span class="o">(</span><span class="n">xsltExecutable</span><span class="o">);</span>
</code></pre>
<p>the code runs fine and the file is parsed and compiled fine, meaning the parser property is taken into account.</p>
<p>Shouldn't that also happen for the direct use of XsltCompiler.compile(file)?</p> Saxon - Feature #5919 (New): Event APIs for writing XML in SaxonCShttps://saxonica.plan.io/issues/59192023-03-13T11:39:42ZMichael Kaymike@saxonica.com
<p>Currently for writing XML using a push-based event API in SaxonCS we only offer the rather antiquated XmlWriter interface.</p>
<p>Internally we include the Push API (Saxon.Hej.s9api.push) and we use this in the InvalidityReportHandler, but we don't expose it for public use.</p>
<p>We also don't include the Sapling API in the SaxonCS product.</p>
<p>We should consider including one or both of the Push API and the Sapling API - or some improved API that combines the best ideas of the two - in the public SaxonCS API.</p> Saxon - Bug #5877 (New): Java-CustomGUID generator is producing the same result when used inside ...https://saxonica.plan.io/issues/58772023-02-10T05:42:35ZThirupathi Molugoori
<p><strong>InputXml:</strong></p>
<pre><code><?xml version=\"1.0\"?>
<Guids>
<serialNum>1</serialNum>
</Guids>
<Guids>
<serialNum>2</serialNum>
</Guids>
</code></pre>
<p><strong>Case1:Using functions inside xslt</strong></p>
<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:func="http://www.xsltfunctions.com"
xmlns:helper="com.test.xslt.function" extension-element-prefixes="helper" version="2.0">
<xsl:template match="TestXML">
<xsl:element name="TestElement">
<xsl:for-each select="./Guids">
<xsl:element name="serialNum">
<xsl:value-of select="serialNum"/>
</xsl:element>
<xsl:element name="TestGuid">
<xsl:value-of select="func:genGuid()"/>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
<xsl:function name="func:genGuid">
<xsl:value-of select="helper:genGUID()"/>
</xsl:function>
</xsl:stylesheet>
**Output **
<?xml version="1.0" encoding="UTF-8"?>
<TestElement>
<serialNum>1</serialNum>
<TestGuid>D5CAF5D4-8C05-408A-B56A-A277A8F33975</TestGuid>
<serialNum>2</serialNum>
<TestGuid>D5CAF5D4-8C05-408A-B56A-A277A8F33975</TestGuid>
</TestElement>
</code></pre>
<p><strong>Case2:If I use the custom function directly inside the for-each(instead of template/function) then also it is producing the same guid as above which is not expected.</strong></p>
<p><strong>Case3:Using template inside Xslt is producing the correct result</strong></p>
<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:helper="com.test.xslt.function" extension-element-prefixes="helper" version="2.0">
<xsl:template match="TestXML">
<xsl:element name="TestElement">
<xsl:for-each select="./Guids">
<xsl:element name="serialNum">
<xsl:value-of select="serialNum"/>
</xsl:element>
<xsl:element name="TestGuid">
<xsl:call-template name="genGUID"/>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
<xsl:template name="genGUID">
<xsl:value-of select="helper:genGUID()"/>
</xsl:template>
</xsl:stylesheet>
</code></pre>
<p><strong>Output:</strong></p>
<pre><code><?xml version="1.0" encoding="UTF-8"?>
<TestElement>
<serialNum>1</serialNum>
<TestGuid>E75AE452-4B7F-4CF8-A6CE-64DE81687384</TestGuid>
<serialNum>2</serialNum>
<TestGuid>771D2C44-8216-4CA7-B43A-2CBEB03AF7F3</TestGuid>
</TestElement>
</code></pre>
<p><strong>Customer function implementation:</strong></p>
<pre><code>package com.test.xslt.function;
import java.util.UUID;
import net.sf.saxon.s9api.ExtensionFunction;
import net.sf.saxon.s9api.QName;
import net.sf.saxon.s9api.SaxonApiException;
import net.sf.saxon.s9api.SequenceType;
import net.sf.saxon.s9api.XdmAtomicValue;
import net.sf.saxon.s9api.XdmValue;
public class GUIDGenFunction implements ExtensionFunction {
@Override
public QName getName() {
return new QName( "com.test.xslt.function", "genGUID" );
}
@Override
public SequenceType[] getArgumentTypes() {
return new SequenceType[]{};
}
@Override
public SequenceType getResultType() {
return SequenceType.ANY;
}
@Override
public XdmValue call( XdmValue[] arguments ) throws SaxonApiException {
String result = UUID.randomUUID().toString().toUpperCase();
System.out.println( "GUID Result " + result );
return new XdmAtomicValue( result );
}
}
ExtensionFunction genGUIDFunction = new GUIDGenFunction();
processor.registerExtensionFunction( genGUIDFunction );
</code></pre>
<p>Please let me know why it is not working as expected in case1&2.</p> Saxon - Feature #5755 (New): Wouldn't it be nice to have an Package Resolver?https://saxonica.plan.io/issues/57552022-12-06T12:23:45ZNico Kutscherauer
<p>The general idea:</p>
<p>Saxon should have a new configuration option where the user can provide a Java class implementing a specific interface. The class should work similar to the <code>URIResolver</code>, just for packages. It receives a package name and a requested version info like it was specified in the <code><xsl:use-package></code> and returns the <code>javax.xml.transform.Source</code> of the package file or <code>null</code> if the package is not available. Any time Saxon compiles a stylesheet containing an <code><xsl:use-package></code> declaration it asks at first the Pakage Resolver for the resource. If it returns <code>null</code> it uses the current logic to get it.</p>
<p>What is the benefit?</p>
<ul>
<li>You could implement a repository based pull mechanism for XSLT packages .In my mind, it's something like Maven already does with its dependency concept. Companies could maintain internal repositories or even an "XSLT central" could be come real.</li>
<li>You could make lookups for packages based on common patterns. For instance I developed an <a href="https://github.com/nkutsche/xslt-package-handler" class="external">XSLT Package Handler</a> which works with the generic initializer option and collects all packages which can be found in the classpath. This would be much more elegant, if it would not use the very generic intializer interface and if it would have a pull mechanism.</li>
</ul>
<p>What do you think?</p> Saxon - Feature #5709 (New): Compiler and target processor information from fn:system-property()https://saxonica.plan.io/issues/57092022-10-04T08:05:03ZDebbie Lockettdebbie@saxonica.com
<p>Add more (saxon namespace) properties to return compile-time infomation about the target processor and compiler using <code>fn:system-property()</code>. Currently we have <code>xsl:product-name</code> and <code>xsl:product-version</code>: when XJ-compiling for JS, evaluated statically these return for instance <code>"SAXON"</code> and <code>"JS 11.4"</code>. Note that the <code>xsl:product-version</code> value is made up of the target edition and compiler version number; but we don't get the compiler edition (EE). The property <code>saxon:platform</code> can also be used (with SaxonJS) to get run-time information about the platform ("Node.js" or "Browser").</p>
<p>(As originally suggested in SaxonJS <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Status: Closed" href="https://saxonica.plan.io/issues/5698">Bug #5698: Changes for system-property()</a>.)</p> Saxon - Bug #5651 (New): Garbage collection of xsl:key indexeshttps://saxonica.plan.io/issues/56512022-08-18T14:24:21ZMichael Kaymike@saxonica.com
<p>When Saxon builds an index in support of an xsl:key definition, or an implicit xsl:key generated by the XSLT/XQuery optimizer, the intent is that the key remains in memory so long as BOTH the source document AND the compiled stylesheet or query remain in memory.</p>
<p>This appears not to be working. If we run the same query 1000 times against the same source document, we're seeing the index built 95 times. This suggests the garbage collector is destroying it and we're having to rebuild it the next time it's used.</p>
<p>We use WeakReferences to support this policy, and it looks as if we're getting it wrong.</p>
<p>Note: we also need to check how this works on Saxon-CS, as it's probably different.</p> Saxon - Bug #5615 (New): Saxon 11 - Cannot have two different documents with the same document-urihttps://saxonica.plan.io/issues/56152022-07-26T11:03:55ZRadu Coravuradu_coravu@sync.ro
<p>I'm getting this unhandled error which comes probably from reusing a transformer, the code we use is quite complex in those parts:</p>
<pre><code>7065 ERROR [ main ] ro.sync.quickfix.QuickFixExecutor - Cannot generate late quick fixes: net.sf.saxon.trans.XPathException: Cannot have two different documents with the same document-uri file:/D:/projects/../SchematronQF/add/element/selectAttrValue/topic.dita
net.sf.saxon.trans.XPathException: Cannot have two different documents with the same document-uri file:/D:/projects/../SchematronQF/add/element/selectAttrValue/topic.dita
at net.sf.saxon.om.DocumentPool.add(DocumentPool.java:69)
at net.sf.saxon.Controller.registerDocument(Controller.java:1004)
at net.sf.saxon.Controller.makeSourceTree(Controller.java:1359)
at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:343)
at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:75)
</code></pre>
<p>would it be a good idea in the Controller.registerDocument to check if the document is already in the pool before adding it?</p>
<pre><code> if (getDocumentPool().find(uri) == null) {
sourceDocumentPool.add(doc, uri);
}
</code></pre> Saxon - Bug #5578 (New): Feature: tracing on .NEThttps://saxonica.plan.io/issues/55782022-06-23T08:38:47ZMichael Kaymike@saxonica.com
<p>See <a href="https://saxonica.plan.io/boards/3/topics/8829" class="external">https://saxonica.plan.io/boards/3/topics/8829</a></p>
<p>The basic tracing infrastructure is present in SaxonCS (the -T option on the command line works), but the APIs to control it are largely missing, and the -TP option (with the underlying TimingTraceListener class) is absent.</p>
<p>The restrictions are not well documented, for example the page "Using XSLT from the command line" does not mark the -TP option as Java-only.</p> Saxon - Bug #5549 (New): Function caching is not applied to tail callshttps://saxonica.plan.io/issues/55492022-05-30T08:11:02ZMichael Kaymike@saxonica.com
<p>If a function f contains a tail-call to a function g, and g is defined with cache="yes", then the cache is ignored and g is executed normally.</p>
<p>See <code>TailCallLoop.tailCallDifferentFunction()</code></p>
<p>(Test case function-1035. I modified the test to make the call not be a tail call; undo this change to demonstrate the problem)</p> Saxon - Support #5469 (New): Combining Configuration Fileshttps://saxonica.plan.io/issues/54692022-05-03T15:25:55ZScott Louzon
<p>To whom it may concern,</p>
<p>I have moved my XSLT creation methodology, in part, to using XSLT packages.
This has been a great new feature over the include/import flow I was previously using.</p>
<p>My last issue is with the encapsulation of the configuration files for pointing to the packages on the cmd-line "-config:".
<a href="https://www.saxonica.com/documentation9.5/configuration/configuration-file/" class="external">https://www.saxonica.com/documentation9.5/configuration/configuration-file/</a>
Unfortunately, I don't see mention of in the example.</p>
<p>Take the following example:
Car package is at the top.
Car package uses Frame, Engine, Wheels, etc.. packages.
Each of the Frame, Engine, Wheel packages could use many other packages, and so on below that.
However, when using the Car package, I don't want to care about the location or structure of everything downstream when building my configuration file for the Car package.</p>
<p>I am wondering what the current methodology recommendation is for building this hierarchy of configuration XML files when using XSLT packages?</p>
<ul>
<li>Always have a "massive" top-level package specify the location of everything you could possibly need to use?</li>
<li>Have a tool (possibly an XSLT) combine all the XML configuration files before-hand, and then use the generated combined file on the command-line?</li>
<li>Some better built in way of pointing to a lower-level configuration file, which in turn can point to the packages it needs, as well as more configuration files?</li>
<li>Don't use configurations files at all, potentially better way to specify package locations and connections?</li>
</ul>
<p>Based on all the information you could pass into a configuration file besides , like XSLT versions and such, I imagine combining configuration files could get tricky.</p>
<p>In general, I want to avoid making a tool to combine XML configuration files in an encapsulated manner, if there is already a better built-in way to do what I want.</p> Saxon - Bug #5067 (New): Stability of collection orderinghttps://saxonica.plan.io/issues/50672021-08-23T11:28:25ZMichael Kaymike@saxonica.com
<p>The spec says that by default collections are stable, so processing the same collection twice should give the same result.</p>
<p>It also says that a collection is a sequence (not a set).</p>
<p>This is difficult to reconcile with Saxon's use of multi-threading to process the items in a collection, which makes the order of processing unpredictable. Perhaps we should be doing multi-threading within the same constraints as <code>xsl:for-each</code> with a <code>threads</code> attribute, where the results are delivered in the original order.</p>
<p>Problem arose from consideration of test case <code>cbcl-collection-002</code> where in Saxon-CS we are delivering the (integer) contents of the collection in an arbitrary order.</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> 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>