Saxon: Helphttps://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2023-12-23T11:14:42ZSaxonica Developer Community
Planio Help: RE: Should fn:transform always return a map with an "output" property or can it return an e...https://saxonica.plan.io/boards/3/topics/9584?r=9587#message-95872023-12-23T11:14:42ZMartin Honnenmartin.honnen@gmx.de
<p>I see.</p>
<p>For the time being I fixed the JavaScript frontend of my SaxonC 12 Python powered XML workbench <a href="https://saxonc-xmlworkbench.azurewebsites.net/" class="external">https://saxonc-xmlworkbench.azurewebsites.net/</a> which uses <code>fn:transform</code> to run XSLT to handle the case when <code>fn:transform</code> returns an empty map and therefore JavaScript receives no result documents (if there have been no secondary result documents) from the Python REST API.</p> Help: RE: Should fn:transform always return a map with an "output" property or can it return an e...https://saxonica.plan.io/boards/3/topics/9584?r=9586#message-95862023-12-22T19:46:31ZMichael Kaymike@saxonica.com
<p>Interesting question.</p>
<p>The spec does say:</p>
<blockquote>
<p>The result of the transformation is returned as a map. There is one entry in the map for the principal result document, and one for each secondary result document.</p>
</blockquote>
<p>But the XSLT 3.0 spec also says:</p>
<blockquote>
<p>In previous versions of this specification it was stated that when the raw result of the initial template or function is an empty sequence, a result tree should be produced if and only if the transformation generates no secondary results (that is, if it does not invoke xsl:result-document). This provision is most likely to have a noticeable effect if the transformation produces serialized results, and these results are written to persistent storage: the effect is then that a transformation producing an empty principal result will overwrite any existing content at the base output URI location if and only if the transformation produces no other output. Processor APIs offering backwards compatibility with earlier versions of XSLT must respect this behavior, but there is no requirement for new processor APIs to do so.</p>
</blockquote>
<p>So there's some deliberate ambiguity about what XSLT delivers by way of serialized output if the principal result is empty, and this presumably carries over into fn:transform.</p> Help: Should fn:transform always return a map with an "output" property or can it return an empty...https://saxonica.plan.io/boards/3/topics/95842023-12-21T10:51:53ZMartin Honnenmartin.honnen@gmx.de
<p>I am wondering why I get an empty map from <code>fn:transform</code> if the principal result is empty, I would nevertheless expect the map to have a property named <code>output</code> with an empty string result.</p>
<p>I am getting different results using <code>fn:transform</code>, depending on whether I use <code>'delivery-format' : 'raw'</code> or <code>'delivery-format' : 'serialized'</code>, in the latter case I am getting an empty map with no <code>output</code> property.</p>
<p>Testing using Saxon HE 12.4:</p>
<p>File 1:</p>
<pre><code>declare namespace output = 'http://www.w3.org/2010/xslt-xquery-serialization';
declare option output:method 'adaptive';
transform(
map {
'delivery-format' : 'raw',
'source-node' : document { <root>test</root> },
'stylesheet-node' : <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all">
<xsl:output method="text"/>
<xsl:template match="/" name="xsl:initial-template">
<xsl:for-each-group select="foo/bar" group-by="baz">
<group count="{{count(current-group())}}"/>
</xsl:for-each-group>
</xsl:template>
</xsl:stylesheet>
}
)
</code></pre>
<p>Output:</p>
<pre><code>map{"output":()}
</code></pre>
<p>File 2:</p>
<pre><code>declare namespace output = 'http://www.w3.org/2010/xslt-xquery-serialization';
declare option output:method 'adaptive';
transform(
map {
'delivery-format' : 'serialized',
'source-node' : document { <root>test</root> },
'stylesheet-node' : <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all">
<xsl:output method="text"/>
<xsl:template match="/" name="xsl:initial-template">
<xsl:for-each-group select="foo/bar" group-by="baz">
<group count="{{count(current-group())}}"/>
</xsl:for-each-group>
</xsl:template>
</xsl:stylesheet>
}
)
</code></pre>
<p>Output:</p>
<pre><code>map{}
</code></pre> Help: RE: Loading JSON from Java API from URL: better call json-doc system function or use JsonBu...https://saxonica.plan.io/boards/3/topics/9571?r=9573#message-95732023-11-27T16:18:25ZMichael Kaymike@saxonica.com
<p>I would have thought the simplest approach was to get a URLConnection from the URI, get an InputStream from the URLConnection, wrap a Reader around this, and pass the Reader to the JsonBuilder. Yes, we could have made that easier; and yes, an alternative is to call json-doc() as an XdmFunction.</p> Help: RE: Loading JSON from Java API from URL: better call json-doc system function or use JsonBu...https://saxonica.plan.io/boards/3/topics/9571?r=9572#message-95722023-11-27T16:11:35ZMartin Honnenmartin.honnen@gmx.de
<p>I have looked through other parts of the source code whether there might be an example loading JSON over HTTP(S) or a URL, kind of expected or hoped to see that done in Query.java and/or Transform.java with <code>-u</code> (<code>-u Indicates that the names of the source document and the stylesheet document are URLs</code>) but it seems <code>-json</code> doesn't support <code>-u</code>.</p>
<p>So my question remains, is using <code>fn:json-doc</code> as a system function the easiest approach to load a JSON document from Java over HTTP(S), to get an XdmValue?</p> Help: Loading JSON from Java API from URL: better call json-doc system function or use JsonBuilder?https://saxonica.plan.io/boards/3/topics/95712023-11-25T17:42:43ZMartin Honnenmartin.honnen@gmx.de
<p>Looking at Saxon 11 and/or 12 Java, I wonder whether I am overlooking a way to load a JSON document from a URL; it seems JsonBuilder, contrary to DocumentBuilder, has no easy option to pass in a URL to load some JSON from.</p>
<p>I wonder whether I am better off to try to call <code>fn:json-doc</code> as a system function with the URL as the argument instead of trying to construct an Reader off the response stream of a URLConnection.</p>
<p>Any thoughts or hints whether I am overlooking something appreciated.</p> Help: RE: Adding Saxon HE to Java classpath makes XML parsing very slowhttps://saxonica.plan.io/boards/3/topics/9475?r=9567#message-95672023-10-27T15:06:34ZMichael Kaymike@saxonica.com
<p>If you discover anything about the initialization path for a Configuration, then of course that would be interesting. It's not something we have devoted a great deal of attention to, since it's usually a one-off cost.</p> Help: RE: Adding Saxon HE to Java classpath makes XML parsing very slowhttps://saxonica.plan.io/boards/3/topics/9475?r=9566#message-95662023-10-27T12:36:23ZMarkus Kargkarg@quipsy.de
<p>I really do share your vision that upfront initialization and then reusing objects is best for performance, and I really would beg you to <strong>not</strong> consider opting out of JAXP. Instead, I will try finding some time to support the JAXB-RI team; possibly they would accept a pull request from me, preventing the repeated <code>TransformerFactory.newInstance()</code> calls.</p>
<p>Nevertheless, I just wanted to share some more benchmarking with you, as there <em>might</em> be potential for optimization still. First of all, you are right with your assumption that the service loader needs long time to check all the JARs. In fact, it eats up two thirds of that six seconds mentioned above (this is easy to simulate, just pass the class name to <code>newInstance()</code> and the search time is gone). OTOH there still is one third left, which I noticed is <em>completely</em> bound to <code>new Configuration()</code>. That rather lengthy constructor actually eats up two of the six seconds, which is incredibly long. Again, I do understand that upfront initialization is best, and I do not know your code in deeper detail so far, but I would not rule out the idea to perform lazy initialization at least for those parts that are unlikely to be used and / or are causing the biggest delays (the idea is: if it is seldomly used, it makes no sense to construct it upfront). And yes, I have read the comment in the code about eaxtly that not being done <em>deliberately</em>.</p>
<p>So I would propose to look into both, JAXB-RI first (as it is definitively done rather badly), followed by <code>new Configuration()</code>. I assume you would be willing to review my changes in case I come up with an efficient solution?</p> Help: RE: Adding Saxon HE to Java classpath makes XML parsing very slowhttps://saxonica.plan.io/boards/3/topics/9475?r=9565#message-95652023-10-27T09:02:34ZMichael Kaymike@saxonica.com
<p>Unfortunately I don't think the performance of <code>TransformerFactory.newInstance()</code> is something we can do much about. It's not a Saxon method, after all, it's a JDK method. I believe the cost is largely that the method searches the classpath opening each JAR file and looking for one with a suitable manifest.</p>
<p>Once Saxon is found, the instantiation creates a new s9api <code>Processor</code> and underlying <code>Configurtation</code>. It's true that this may execute a fair bit of initialisation code, which is intended to be one-time-only code, so an application that does this repeatedly is certainly behaving inefficiently. We could consider deferring this cost until first use of the TransformerFactory; but I think it's unlikely that anyone creates a <code>TransformerFactory</code> and never uses it, so we would only be moving the cost.</p>
<p>Generally I think we have implemented <code>TransformerFactory</code> the way it is designed to be implemented, and if someone is misusing it, that's not really our problem.</p>
<p>We could consider, in a future release, opting out of JAXP by putting all the factory classes in a separate JAR file which doesn't need to be on the classpath unless you actually want to invoke Saxon using JAXP.</p> Help: RE: Adding Saxon HE to Java classpath makes XML parsing very slowhttps://saxonica.plan.io/boards/3/topics/9475?r=9564#message-95642023-10-27T08:55:13ZMarkus Kargkarg@quipsy.de
<p>I got some more information for you, hoping you can see something that can get improved in Saxon itself: It seems the problem is that JAXB is calling <code>TransformerFactory.newInstance()</code> <em>not just once</em> (as one would expect) but it actually calls it <em>several</em> times. This is not much of a problem with the JDK's bundled implementation (which only needs few ms to return a new instance), so I think this is why the JAXB team did not care so far (BTW, even the latest JAXB implementation does that IIUC its current source code on Github). Using Saxon it becomes a problem, as I have benchmarked that calling <code>TransformerFactory.newInstance()</code> one hundred times consumes approx. five seconds on Saxon 12.3 but only 250 ms using JDK's bundled implementation. Or in other words: Saxon's bootstrap is 20 times slower. I have no knowledge of Saxon's internals, but I do assume that 20 times is a factor that could get improved?</p> Help: RE: Can I set the ResourceResolver for fn:transform execution used in XPath evaluation?https://saxonica.plan.io/boards/3/topics/9557?r=9563#message-95632023-10-24T16:30:40ZNorm Tovey-Walsh
<blockquote>
<p>Wow, Norm, already fixed, with a unit case, all, as far as the saxonica.plan.io site tells,<br>
within a few minutes. You are really doing a good "Michael Kay" impression if you keep up that<br>
responsiveness and speed... :)</p>
</blockquote>
<p>Thanks. :-) I aim to please. And I really appreciate your attention to<br>
detail when providing reproducible tests for issues!</p>
<p>Be seeing you,<br>
norm</p>
<p>--<br>
Norm Tovey-Walsh<br>
Saxonica</p> Help: RE: Can I set the ResourceResolver for fn:transform execution used in XPath evaluation?https://saxonica.plan.io/boards/3/topics/9557?r=9562#message-95622023-10-24T15:58:22ZMartin Honnenmartin.honnen@gmx.de
<p>Wow, Norm, already fixed, with a unit case, all, as far as the saxonica.plan.io site tells, within a few minutes. You are really doing a good "Michael Kay" impression if you keep up that responsiveness and speed... :)</p> Help: Can I set the ResourceResolver for fn:transform execution used in XPath evaluation?https://saxonica.plan.io/boards/3/topics/9557?r=9561#message-95612023-10-24T14:44:39ZNorm Tovey-Walsh
<blockquote>
<p>I am wondering whether I can or cannot expect the ResourceResolver set<br>
on XPath evaluation, if the XPath does fn:transform, to be passed on<br>
and used during compilation and execution of the stylesheet run by<br>
fn:transform.</p>
</blockquote>
<p>It seems like a reasonable expectation.</p>
<p>What’s happening today is that the fn:transform function creates a new<br>
Xslt30Transformer to do the transformation but it doesn’t set the<br>
resource resolver on that transformer to the resolver from the<br>
XPathContext passed in. I think it should.</p>
<p>See issue <a class="issue tracker-1 status-7 priority-1 priority-lowest closed" title="Bug: fn:transform doesn't use the resource resolver from the XPathContext (Resolved)" href="https://saxonica.plan.io/issues/6230">#6230</a></p>
<p>Be seeing you,<br>
norm</p>
<p>--<br>
Norm Tovey-Walsh<br>
Saxonica</p> Help: RE: Can I set the ResourceResolver for fn:transform execution used in XPath evaluation?https://saxonica.plan.io/boards/3/topics/9557?r=9560#message-95602023-10-23T18:26:05ZMartin Honnenmartin.honnen@gmx.de
<p>Thanks, Norm, I hope to hear from you tomorrow.</p> Help: RE: Can I set the ResourceResolver for fn:transform execution used in XPath evaluation?https://saxonica.plan.io/boards/3/topics/9557?r=9559#message-95592023-10-23T17:09:47ZNorm Tovey-Walsh
<blockquote>
<p>Saxon - Help: RE: Can I set the ResourceResolver for fn:transform execution used in<br>
XPath evaluation?</p>
<p>Martin Honnen</p>
<p>Hey Saxonicans,</p>
<p>any comments/thoughts on this?</p>
</blockquote>
<p>I will try to investigate this tomorrow. I thought I’d get to it today,<br>
but…apparently not. :-(</p>
<p>Be seeing you,<br>
norm</p>
<p>--<br>
Norm Tovey-Walsh<br>
Saxonica</p>