Saxon

Legacy ID: #6352894 Legacy Poster: Michael Kay (mhkay)

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.

Legacy ID: #6377133 Legacy Poster: curry (matek994)

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. /Mats PS: BTW, thanks for offering a great XSLT2 library!

Legacy ID: #6377574 Legacy Poster: Michael Kay (mhkay)

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.

Legacy ID: #6385585 Legacy Poster: curry (matek994)

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. /Mats PS: BTW, thanks for offering a great XSLT2 library!

Legacy ID: #6385850 Legacy Poster: curry (matek994)

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?...

Legacy ID: #6385892 Legacy Poster: Michael Kay (mhkay)

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. Michael Kay