Saxon.js on the server?

[streaps]

Would it be possible to make a version that could run on node.js?

[michaelhkay]

No, this is not possible using the GWT technology on which Saxon-CE depends. GWT explicitly targets the browser environment.

Michael Kay
Saxonica

On 13 Oct 2013, at 13:23, streaps wrote:

Would it be possible to make a version that could run on node.js?

—
Reply to this email directly or view it on GitHub.

[rimmartin]

Hi,
for nodejs I put some c++ glue together to make a V8/node module work with Saxon/C http://www.saxonica.com/saxon-c/index.xml instead of Saxon-CE. Typical node code is

try
{
    var content = yield fs.readFile(global.inputXmlPath, "utf8");
    var saxonProcessor = new saxon.SaxonProcessor(false);
    var xsltProcessor = saxonProcessor.newTransformer();
    xsltProcessor.compile(global.xslPath);
    xsltProcessor.parseXmlString(content);
    var pdbContent = xsltProcessor.xsltApplyStylesheet();
    console.dir(pdbContent);
}
catch (err) {
console.dir(err.message);
}

Works like a charm. It is based on nodejs --harmony using the new yields and generators.

Would this be of interest to the xslt and node communities?

To do: I need to implement parameters and properties. Can readily add xquery processor as well.

[rimmartin]

Forgot; tested this on Ubuntu; it should be possible to make it portable to mac and Windows too

[ond1]

Hi Martin,

Node.js is an interest technology that I never got around to trying out or needed to use. However, Saxon/C and node.js seems like an project worth pursuing from an XSLT prospective.

I have added the xsl-list and the Saxon mailing-list to this email to see if anyone from the XSLT community who has experience of using node.js would find this project of use and interesting.

Kind regards,

O'Neil

On 6 Jan 2015, at 23:27, rimmartin [email protected] wrote:

Hi,
for nodejs I put some c++ glue together to make a V8/node module work with Saxon/C http://www.saxonica.com/saxon-c/index.xml http://www.saxonica.com/saxon-c/index.xml instead of Saxon-CE. Typical node code is

try
{
var content = yield fs.readFile(global.inputXmlPath, "utf8");
var saxonProcessor = new saxon.SaxonProcessor(false);
var xsltProcessor = saxonProcessor.newTransformer();
xsltProcessor.compile(global.xslPath);
xsltProcessor.parseXmlString(content);
var pdbContent = xsltProcessor.xsltApplyStylesheet();
console.dir(pdbContent);
}
catch (err) {
console.dir(err.message);
}
Works like a charm. It is based on nodejs --harmony using the new yields and generators.

Would this be of interest to the xslt and node communities?

To do: I need to implement parameters and properties. Can readily add xquery processor as well.

—
Reply to this email directly or view it on GitHub #1 (comment).

---

O'Neil Delpratt
Software Developer, Saxonica Limited
Email: [email protected]
Tel: +44 118 946 5894
Web: http://www.saxonica.com
Saxonica Community site: http://dev.saxonica.com
Bug tracking site: https://saxonica.plan.io/

[ond1]

Message from Rob Koberg from the [email protected] http://lists.mulberrytech.com/ in regards to Saxon/C and Node.js:

This will have problems because you are using a string instead of a
file. The base path of the input document will resolve to the script
rather than the location of the XML. This is also a problem for many
of the node/xml modules, because they mostly (from what I can tell)
convert the file into a string before the parse.

I use grunt to call out to the command line to trigger an ant build file task.

On 6 Jan 2015, at 23:27, rimmartin [email protected] wrote:

Hi,
for nodejs I put some c++ glue together to make a V8/node module work with Saxon/C http://www.saxonica.com/saxon-c/index.xml http://www.saxonica.com/saxon-c/index.xml instead of Saxon-CE. Typical node code is

try
{
var content = yield fs.readFile(global.inputXmlPath, "utf8");
var saxonProcessor = new saxon.SaxonProcessor(false);
var xsltProcessor = saxonProcessor.newTransformer();
xsltProcessor.compile(global.xslPath);
xsltProcessor.parseXmlString(content);
var pdbContent = xsltProcessor.xsltApplyStylesheet();
console.dir(pdbContent);
}
catch (err) {
console.dir(err.message);
}
Works like a charm. It is based on nodejs --harmony using the new yields and generators.

Would this be of interest to the xslt and node communities?

To do: I need to implement parameters and properties. Can readily add xquery processor as well.

—
Reply to this email directly or view it on GitHub #1 (comment).

---

O'Neil Delpratt
Software Developer, Saxonica Limited Email: [email protected]
Tel: +44 118 946 5894
Web: http://www.saxonica.com
Saxonica Community site: http://dev.saxonica.com
Bug tracking site: https://saxonica.plan.io/

[rimmartin]

This is but one of the methods replicated from the SaxonProcessor.cpp and XsltProcessor.cpp provided in the Saxon/C interface. The straight file is another method. For me I don't have files because I'm using RESTful interfaces so this was an illustration of doing it. The methods of http://www.saxonica.com/saxon-c/doc/html/XsltProcessor_8h_source.html are being added(but not wrapped) directly to the module

[rimmartin]

For files it is/will be possible to code:

var pdbContent = xsltProcessor.xsltApplyStylesheet(global.inputXmlPath);

The objective is to bring in the stylesheet once, compile it once and apply multiple times

[rimmartin]

 XsltProcessor(SaxonProcessor* proc, bool license=false, string cwd="");

can set the working directory

[ond1]

Had some interest in a private email. One person said especially if we can call the XML Schema 1.1 validator. We intend to provide EE support in the next release.

How can I setup Saxon/C with node.js to play with it myself.
kind regards,

O’Neil

On 7 Jan 2015, at 13:17, rimmartin [email protected] wrote:

This is but one of the methods replicated from the SaxonProcessor.cpp and XsltProcessor.cpp provided in the Saxon/C interface. The straight file is another method. For me I don't have files because I'm using RESTful interfaces so this was an illustration of doing it. The methods of http://www.saxonica.com/saxon-c/doc/html/XsltProcessor_8h_source.html http://www.saxonica.com/saxon-c/doc/html/XsltProcessor_8h_source.html are being added(but not wrapped) directly to the module

—
Reply to this email directly or view it on GitHub #1 (comment).

---

O'Neil Delpratt
Software Developer, Saxonica Limited Email: [email protected]
Tel: +44 118 946 5894
Web: http://www.saxonica.com
Saxonica Community site: http://dev.saxonica.com
Bug tracking site: https://saxonica.plan.io/

[rimmartin]

I'll stand up a github project tonight after work and give you a script to pull and try it. There aren't many dependencies:

    "dependencies" : {
        "co" : "4.0.0",
        "co-fs" : "1.2.0",
        "should" : "4.3.0",
        "mocha-co" : "1.17.1-co.1"
    },

and native Saxon/C and needs to be at least nodejs v0.11.x for the --harmony switch

[rimmartin]

Thinking parameters can be added to the javascript

xsltProcessor.parameters.elements-of-interest="'C', 'H'";

and be used during the transformations

[eric-brechemier]

I am also interested in trying it out: it would make it easier to integrate Saxon XSLT transformations to generate static pages in Web development projects where other developers already have node.js installed, but may be reluctant to install Ant + a Java JDK.

[ond1]

On 8 Jan 2015, at 10:53, Eric Bréchemier [email protected] wrote:

but may be reluctant to install Ant + a Java JDK.

Would not think you need to install Ant + a Java JDK. The Saxon/C library has everything you need in a self contained package.

---

O'Neil Delpratt
Software Developer, Saxonica Limited Email: [email protected]
Tel: +44 118 946 5894
Web: http://www.saxonica.com
Saxonica Community site: http://dev.saxonica.com
Bug tracking site: https://saxonica.plan.io/

[eric-brechemier]

Well, I haven't tried Saxon/C yet, but a layer of scripting is typically needed to configure the flow of transformations, and I am not going to write it in C++.

Apache Ant offers portability for this type of scripts.

[rimmartin]

The repository is
https://github.com/rimmartin/saxon-node

Will add the direct file, parameters and properties over the weekend. Any particular feature needed?

Will pull to my work computer and make a typical script to use npm to install, build with gyp and run the one lonely test.

Next week will publish it so npm can pull it into other projects

[rimmartin]

I got a bit of saw dust; rewriting to call the Saxon/C SaxonProcessor and XsltProcessor objects. Hold off trying it for a bit....

[ond1]

Sure. I probably won’t get a chance to look at it until tomorrow.

On 8 Jan 2015, at 16:22, rimmartin [email protected] wrote:

I got a bit of saw dust; rewriting to call the Saxon/C SaxonProcessor and XsltProcessor objects. Hold off trying it for a bit....

—
Reply to this email directly or view it on GitHub #1 (comment).

---

O'Neil Delpratt
Software Developer, Saxonica Limited Email: [email protected]
Tel: +44 118 946 5894
Web: http://www.saxonica.com
Saxonica Community site: http://dev.saxonica.com
Bug tracking site: https://saxonica.plan.io/

[rimmartin]

Ok, reconstructed and it is possible to test. Next week it will have more features

[eric-brechemier]

I installed Saxon/C using the setup script (32 bits), and I installed nodejs v0.11.14 from source, on Ubuntu 12.04. So far so good.

The installation of saxon-node with npm fails during node-gyp rebuild.

An error is reported:
cc1plus: error: unrecognized command line option ‘-std=c++11’

[rimmartin]

You'll need a compiler compatible with c++11 standard and later.  gcc is 4.7 and later.  I'll write more about the compiler in the readme.md.  I haven't tried 32 bit yet but nothing is set to require 64 bit

https://gcc.gnu.org/projects/cxx0x.html
g++ --version
or are you using clang++ ? 3.3 and later
http://clang.llvm.org/cxx_status.html

 On Wednesday, January 21, 2015 1:08 PM, Eric Bréchemier <[email protected]> wrote:

I installed Saxon/C using the setup script (32 bits), and I installed nodejs v0.11.14 from source, on Ubuntu 12.04.The installation of saxon-node fails during node-gyp rebuild.An error is reported:
cc1plus: error: unrecognized command line option ‘-std=c++11’—
Reply to this email directly or view it on GitHub.

[eric-brechemier]

@rimmartin I would rather avoid recompiling, which requires (parts of) a Java JDK if I understand this bit from your README correctly:

For the build phase, as with integrating Saxon/C interface code the jni.h is needed. Set JAVA_HOME and the binding.gyp locates the jni.h from there.

I feel like it would be easier to include the Saxon/C libraries and the precompiled JavaScript binding code bundled in the saxon-node module. Does it make sense?

[rimmartin]

I'll be writing a clearer readme.md.
The libsaxon.so is already compiled and is used as shared.  What is compiling and still needing the jni.h is some interface source code that comes with Saxon/C in the folder ./Saxon-HEC0.3.1/Saxon-C-API.  Albeit, I've made some small alterations to this interface code which will be included in Saxon/C's next release; for the time being my working copy is pushed into the saxon-node/src folder and the binding.gyp https://github.com/rimmartin/saxon-node/blob/master/binding.gyp knows where everything is by the JAVA_HOME and the SAXON_HOME. jni.h header is the only thing it uses of the jdk; does not link to any native jdk libraries.

You do not need to get the Excelsior JET [- Java Virtual Machine (JVM) and Native Code Compiler] and compile the libsaxon.so; Saxonica does that and has worked out the only license needed is Saxonica's.
The binding.gyp is being conditioned to have the build for linux, mac and windows.  I'll work on the mac version in the next couple of days.  For windows my working copy is compiling but not linking with the msbuild tool yet.
To run after compiling you will not need JAVA_HOME
Let me know if this helps and if this gets you further

[rimmartin]

@eric-brechemier - Ah you're thinking about prebuilt and completely packaged ready to go. Have to think about where I would put such releases for download. Currently this is geared toward publishing as a module on https://www.npmjs.com/package/saxon-node where it can be included in other node project's package.json and build with everything else that package includes.

[eric-brechemier]

@rimmartin

Ah you're thinking about prebuilt and completely packaged ready to go.

Exactly.

Currently this is geared toward publishing as a module on https://www.npmjs.com/package/saxon-node where it can be included in other node project's package.json and build with everything else that package includes.

The Saxon/C libraries alone are not that large... but if you don't want to include a bundle for all platforms, perhaps the install could download the prebuilt library that corresponds to the target platform?

Is the extra compilation step still needed in this case?

[rimmartin]

Yea the glue code src/SaxonProcessor.cpp [a working copy from ./Saxon-HEC0.3.1/Saxon-C-API] still needs to compile; it is not source that is already compiled into libsaxon.so. It is compiled/linked directly with the https://github.com/rimmartin/saxon-node/blob/master/src/SaxonProcessorJS.hpp the native v8/nodejs code and the runtime of it is in /build/Release/obj.target/saxon.Xslt.node file

[rimmartin]

@eric-brechemier I'm looking for what is done to deploy or deliver prebuilt node modules and how parent node projects would call them; learn how to package for it. If it is possible. (my Ubuntu is 14_04). Or I could build it on amazon ec2 with Ubuntu 12_04, zip it up and email it to you. Know more by this weekend

[eric-brechemier]

@rimmartin Thanks for looking into it, I appreciate. Don't worry about my particular target platform; I can contribute the build for Ubuntu 12.04 (32 bit) if it comes to this.

[codan84]

Has anyone got a list of dependencies for this to build? I am trying to build it on OSX and getting a lot of errors like so:

In file included from ../src/SaxonProcessorJS.cxx:7:
../src/SaxonProcessorJS.hpp:27:14: error: no type named 'shared_ptr' in namespace 'std'
    std::shared_ptr<SaxonProcessor> processor;

When building on CentOS VM I get different errors:

File "/usr/local/n/versions/node/0.12.5/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/input.py", line 238, in LoadOneBuildFile
None)
File "binding.gyp", line 1
{
 ^
SyntaxError: invalid syntax
gyp ERR! configure error 

These are lines cut from a middle of many, many lines of debug output. I can post full messages if needed...