Content-Type: multipart/related; boundary="------------010102010004040700040702" --------------010102010004040700040702 Content-Type: text/html; charset=windows-1257 Content-Transfer-Encoding: 8bitSince XSLT 3.0 is currently only a working draft and not necessarily stable, Saxon currently behaves as an XSLT 3.0 processor only if you select this as your language version from the command line or API. By default, it behaves as an XSLT 2.0 processor.
--------------010102010004040700040702 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID:
Its seems that with this property all works.
I have one another answer:
Is it possible to compile only XSLT 3.0 version if I set compiler.XsltLanguageVersion=3.0
If I set compiler.XsltLanguageVersion=2.0 for 3.0 to be an error.
Or I have to do this checking xslt atribute, that of course works
SIA ABC software
Tālr.: +371-67082622 Fakss: +371-67082610
We have managed to fix the bug you reported, which will be available in the next maintenance release of Saxon 9.4.
We generate byte code (from XQuery or XSLT source) using ASM and load/execute it. The problem proved to be a class loader issue within the CompilerService class, which as Mike suggested is associated with the byte code generation. We have therefore simplified the use of the class loader when generating byte code, which did seem to get 'mixed-up' across .NET through the IKVM.
On 20/03/2012 10:15, Michael Kay wrote:
OK, thanks, we have reproduced the failure.
This is associated with byte code generation, so you can work around the problem by adding the API call
The reason the 3.0 streamable example works is that byte code generation is automatically switched off for streamable templates.
What's happening here, as far as we can tell, is that we are generating byte code corresponding to your XSLT stylesheet; we are then translating the byte code to IL code using IKVMC. The byte code that we generate is a class which inherits from the class com.saxonica.bytecode.map.CompiledContextMappingFunction, which is present in saxon9ee.dll. When we run from within the command line Transform command, which is in the same DLL, this is successfully loaded, but when we run from a different DLL, a failure occurs when attempting dynamic loading of the superclass.
One of the puzzles is how something so simple is failing when all our tests worked OK - but I suspect that observation won't help us in finding the cause and fixing it.
As we've reproduced the problem, we should be able to find a fix. My colleague O'Neil Delpratt will be working on this.
On 19/03/2012 08:24, Aleksandrs Zeļikovičs wrote:
Thank you for your answer,
Before buying saxonica application for our product we test it with simplest XSLT.
We will have catalog with xslt (not only 3.0).
Interesting that under Console application all XSLT can be run.
Testing your product, this XSLT cant be run Under windows project:
1.0 Exception in Compile: com.saxonica.bytecode.map.CompiledContextMappingFunction
<xsl:output method="xml" encoding="UTF-8" indent="yes"/>
------------------------------------------------------------------------------This SF email is sponsosred by:Try Windows Azure free for 90 days Click Here
_______________________________________________saxon-help mailing list archived at http://saxon.markmail.org/
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4881 - Release Date: 03/19/12