Saxon XSLT 3

[Joao S. O. Bueno]

Oh, I see.

I thought it used some kind of code transpilation into pure C++

On Thu, Jul 10, 2025 at 12:38 PM Rene Engelhard <rene at debian.org> wrote:
>
> Hi,
>
> Am 10.07.25 um 04:10 schrieb Joao S. O. Bueno:
> >  From reading the things on the Saxon project page (saxonica.com), I
> > understood that the "SaxonC-HE" part is derived by them from the Java
> > sources and is a C++ framework,
>
> That is the GraalVM thingy:
>
>  From README.md:
>
> "# SaxonC-HE 12.8.0 source download:
>
> SaxonC-HE is a compiled variant of Saxon from the Java
> platform to the C/C++ platform using GraalVM native-image.
>
> "
>
> And:
>
> rene at frodo:~/Downloads/SaxonCHE-source-12-8-0/src$ find .
> .
> ./main
> ./main/java
> ./main/java/net
> ./main/java/net/sf
> ./main/java/net/sf/saxon
> ./main/java/net/sf/saxon/option
> ./main/java/net/sf/saxon/option/cpp
> ./main/java/net/sf/saxon/option/cpp/DocumentBuilderForCpp.java
> ./main/java/net/sf/saxon/option/cpp/XdmUtils.java
> ./main/java/net/sf/saxon/option/cpp/XsltProcessor.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCCurrentException.java
> ./main/java/net/sf/saxon/option/cpp/ProcessorDataAccumulator.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCExceptionIntHandler.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCExceptionCCharHandler.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCResultDocumentHandler.java
> ./main/java/net/sf/saxon/option/cpp/XQueryEngine.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCExceptionCLongPointerHandler.java
> ./main/java/net/sf/saxon/option/cpp/NativePlatform.java
> ./main/java/net/sf/saxon/option/cpp/MapData.java
> ./main/java/net/sf/saxon/option/cpp/SchemaValidatorForCpp.java
> ./main/java/net/sf/saxon/option/cpp/package-info.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCErrorReporter.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCException.java
> ./main/java/net/sf/saxon/option/cpp/PathHelper.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCAPI.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCMessageListener.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCExceptionDoubleHandler.java
> ./main/java/net/sf/saxon/option/cpp/SaxonCExceptionLongHandler.java
> ./main/java/net/sf/saxon/option/cpp/XPathProcessor.java
> ./main/java/net/sf/saxon/option/cpp/XdmValueForCpp.java
> ./main/java/net/sf/saxon/option/cpp/Xslt30Processor.java
> ./main/c
> ./main/c/include
> ./main/c/include/saxonc
> ./main/c/include/saxonc/XdmAtomicValue.h
> ./main/c/include/saxonc/SchemaValidator.h
> ./main/c/include/saxonc/XQueryProcessor.h
> ./main/c/include/saxonc/SaxonApiException.h
> ./main/c/include/saxonc/DocumentBuilder.h
> ./main/c/include/saxonc/XsltExecutable.h
> ./main/c/include/saxonc/XdmMap.h
> ./main/c/include/saxonc/SaxonProcessor.h
> ./main/c/include/saxonc/saxonc_version.h
> ./main/c/include/saxonc/SaxonCGlue.h
> ./main/c/include/saxonc/Xslt30Processor.h
> ./main/c/include/saxonc/XPathProcessor.h
> ./main/c/include/saxonc/saxonc-core.h
> ./main/c/include/saxonc/XdmValue.h
> ./main/c/include/saxonc/XdmFunctionItem.h
> ./main/c/include/saxonc/SaxonCProcessor.h
> ./main/c/include/saxonc/XdmItem.h
> ./main/c/include/saxonc/XdmArray.h
> ./main/c/include/saxonc/XdmNode.h
> ./main/c/include/saxonc/SaxonCXPath.h
> ./main/c/include/saxonc_export.h
> ./main/c/lib
> ./main/c/lib/XdmArray.cpp
> ./main/c/lib/XsltExecutable.cpp
> ./main/c/lib/XdmFunctionItem.cpp
> ./main/c/lib/saxonc_version.c
> ./main/c/lib/SaxonCProcessor.c
> ./main/c/lib/SaxonProcessor.cpp
> ./main/c/lib/SaxonApiException.cpp
> ./main/c/lib/XQueryProcessor.cpp
> ./main/c/lib/XdmAtomicValue.cpp
> ./main/c/lib/XdmNode.cpp
> ./main/c/lib/SchemaValidator.cpp
> ./main/c/lib/XdmItem.cpp
> ./main/c/lib/XdmMap.cpp
> ./main/c/lib/XPathProcessor.cpp
> ./main/c/lib/SaxonCGlue.c
> ./main/c/lib/XdmValue.cpp
> ./main/c/lib/DocumentBuilder.cpp
> ./main/c/lib/Xslt30Processor.cpp
> ./main/c/lib/SaxonCXPath.c
> ./main/c/bin
> ./main/c/bin/Transform.c
> ./main/c/bin/Query.c
>
> Which then would need GraalVM to be built and packaged for building libreoffice. Which is a no-go in many cases, even if it was possible.
>
> > Although, looking at the footprint it takes, it really surprises me
> > there are no lighter-weight libs that could perform the same
> > functionality.
>
> Exactly.
>
>
> Regards,
>
>
> Rene
>