Saxon

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

Where does the node come from? Is it in a tree that is already known to the transformation, or is it loaded "out of the blue"? >I do not found the way to translate an XmlElement (or XmlNode) to a net.sf.saxon.om.NodeInfo Basically, an XmlElement can be wrapped in a net.sf.saxon.dotnet.NodeWrapper to make it implement the NodeInfo interface. I'm afraid there are quite a few limitations in the area of extension functions in the .NET product, and I'm having trouble working out exactly what they are because debugging in this environment isn't easy. I did actually spend a bit of effort on this last week but didn't make much progress - I was trying to make the code for handling extension functions sensitive to the types defined in the Saxon.Api module (such as XdmValue) but I was hitting a lot of problems with introducing a reverse dependency from saxon9.dll into saxon.api.

Legacy ID: #4675730 Legacy Poster: Bruno Chatel (bcha)

Thanks for your rapid response. >Where does the node come from? Is it in a tree that is already known to the transformation, or is it loaded "out of the blue"? It comes from a totally different context (from an XmlDocument managed in C# application). Is it possible in this case ? >Basically, an XmlElement can be wrapped in a net.sf.saxon.dotnet.NodeWrapper to make it implement the NodeInfo interface. Sorry, but can you provide a little sample of code using NodeWrapper to process it (I have searched without success). -- bruno --

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

I can't actually give you a guarantee that this will work, because I don't think it's included in my test cases. You can wrap an XmlNode that represents a document node using the constructor new net.sf.saxon.dotnet.DocumentWrapper(XmlNode doc, String baseURI, Configuration config) If you don't know a base URI you can invent one; this is probably safer than supplying null. The Configuration can be obtained either from the Processor object in the API, or by defining an XPathContext argument to your extension function and navigating from the context object to the Configuration (context.getController().getConfiguration()). Having wrapped the Document node, you can then wrap any other node in the same document using the method documentWrapper.wrap(XmlNode node) and the result is an object of class net.sf.saxon.dotnet.NodeWrapper, which implements net.sf.saxon.om.NodeInfo, and which can therefore be returned as the result of your extension function. It's desirable that if your function is called repeatedly, you should only create one DocumentWrapper for the document node. If you create multiple wrappers, the nodes are considered to be distinct nodes when it comes to comparing node identity and eliminating duplicates. Michael Kay

Legacy ID: #4675845 Legacy Poster: Bruno Chatel (bcha)

Ok I have found a work-around (but not really efficient) by returning a string (XmlElement.OuterXml) and getting it in an XSLT function that build a required element (using saxon:parse). If your proposal does not succeed, I'll use this work-around. Many thanks -- bruno --