I am trying to make use of the Calabash XProc library (which uses Saxon 9(.?) libraries, i.e. saxon9.jar and saxon9-s9api.jar) in one of my ASP.NET 3.5 applications. The Calabash is implemented in Java, and I have managed to convert it to a DLL using ikvmc (v 0.38.0.2). When generating the DLL, the Saxon classes are also included. Now, when coding against the Calabash API from my .NET application, I need to pass Saxon XML trees, which I need to load from the file system. And to load a file I need to use java.io classes. I remember I used Saxon.NET in another project, and this allowed me to use the .NET system.io classes, which of course is more convenient. My question is, can I somehow have the .NET facade for the Saxon classes added on, such that I can generate Saxon XML trees using .NET's XmlReaders, and then have these passed to the Calabash library?
Some tricky stuff here!
Saxon on .NET does not include the s9api library. I think you could attempt to compile Calabash and s9api using ikvmc, and then run this against the saxon9.dll issued with Saxon on .NET. I can't guarantee that will work, but I can't see any reason why it shouldn't. (If it doesn't, you can always try rebuilding an equivalent to saxon9.dll with your own modifications; the important thing is that it contains the classes in the net.sf.saxon.dotnet package). You should then be able to take advantage of the .NET integration features that come with saxon9.dll (such as integration with the System.Xml parsers and DOM implementation), and of course you can use the Saxon.Api namespace as well.
You may hit a few issues that might require source changes to fix, for example the whole thing has to run under a single Configuration, yet both the s9api and Saxon.Api front-ends insist on creating the Configuration for you, which means they cannot coexist sharing the same Configuration.
Generally, this all sounds ambitious but feasible; it could be a rough ride.
Thanks for your quick answer Michael!
Ok, as for the packaging, I think I have managed to get it to work... I had to re-NETify the Saxon jars since all dependencies have to use the same IKVM runtime version (or something)...
Regarding the single Configuration issue, something in me agrees that this is a potential problem. But I cannot say I understand fully why. I will use Saxon in my app to create some XdmNodes that I will pass to Calabash, and Calabash may return some XdmNodes to my app. I may of course also use Saxon for other tasks in my app, but which are mostly unrelated with Calabash. So for this, why is it required that there is a single Configuration? Does an XdmNode carry a reference to the Configuration? I cannot assume it is a stand-alone object?... Guess I need to learn the internals of Saxon to answer this...
On a related issue, I understand I may have to make use of the wrap/unwrap facilities to marshall between JAVA and .NET versions of the XdmNode types (Calabash works with the former). My current plan is to hide this issue by imitating Saxon's way of providing a .NET API, i.e. I will develop a .NET front-end API to Calabash so that all Java is hidden from the application. Perhaps I could manage to hide workarounds to the issues discussed above within that layer.
PS: BTW, thanks for offering a great XSLT2 library!
Technically, you don't need a single Configuration, but a single NamePool, which amounts to the same thing. All compiled stylesheets and queries and all built documents (e.g. XDMNode) represent names in the form of integer codes which are translated into strings via the NamePool. You can of course have multiple Configurations or NamePools but nodes belong to one or the other and can't be mixed.
Oops, sorry for that duplicate post.
Ok, perhaps I have to rethink a bit. As mentioned, I'm planning on implementing a .NET front-end wrapper API for the Calabash library, similar to the Saxon.Api. If in that API, I pass and return XmlNodes rather than XdmNodes, and make use of the wrap/build methods, then perhaps the single Configuration issue is resolved? Guessing this may incur a performance penalty, but it might be worth it, and should not be as bad as passing serialized representations of the xml trees, right?...
I haven't looked at the performance of the Microsoft DOM wrapper code - the Java equivalent is pretty bad, because of the awful way DOM handles namespaces, and complications like merging adjacent text nodes. From a performance point of view, the best thing would be to expose nodes in their native Saxon representation as net.sf.saxon.om.NodeInfo objects, which is also the common representation underneath both s9api and Saxon.Api.
If you're not using Saxon.Api then the single Configuration requirement shouldn't be a problem: let Calabash create the Configuration, and then you can use it in your code; it's accessible from any NodeInfo.