3
votes

I'm building a new API for an existing service. The methods in it will be called from with in XSLT as .net extensions however I can see me needing to use the same API to do some .net XML juggling too.

I've been toying which how best to write this all night. For it to be XSLT friendly I'll be returning XML in a XPathNavigator object so the XSLT can work with it straight away (rather than convert it into a node set in the XSLT. But XPathNavigators make me shudder if using them from within .net and I would much rather use a XmlDocument (or XDocument) any day over a XPathNavigator.

So choices, choices, what to return?

My current thought is to write it all to use XmlDocuments and then write a Wrapper that will be used by the XSLT, this would simply call the main API and then generate a XPathNavigator from the returned XmlDocument. Its a few more hoops to jump through but would be the most flexible.

Any thoughts on my reasoning or if you have any better suggestions.

Cheers

Pete

2
Ummm... I don't think this is an XSLT question. Also it looks very subjective I would much rather use a XmlDocument (or XDocument) any day over a XPathNavigator without requeriments or use cases. - user357812
I added the "xslt" tag as I was after .net users with xslt experience who would know how to write .net extensions with xslt in mind. Yes its subjective as I don't know which way to go with it and am looking for guidance. - Pete Duncanson

2 Answers

4
votes

Methods that accept or return XML should favor returning XmlReader or XPathNavigator unless the user is expected to be able to edit the XML data, in which case XmlDocument should be used.

Source: Best Practices for Representing XML in the .NET Framework (ยง Methods that Accept XML Input or Return XML as Output)

2
votes

I didn't look through the whole API but XmlDocument : XmlNode : IXPathNavigable

And it seems most functions of XslTransform have overloads that accept IXPathNavigable.

So, check if this covers what you need but returning IXPathNavigable could be an elegant solution.

The XDocument family is not very XSLT friendly.