Saxon

I can't say I particularly like the .NET design style of providing zillions of overloads of a method - it always seems to me that this suggests there's some abstraction missing. On the 11 branch we've introduced ActiveSource as the missing abstraction internally, but we're not really using it in the Saxon.Api level.

On the other hand we've already got 8 overloads so the natural way of extending it is to add a couple more... It's not so much the thin end of the wedge, as the thick end.

Another approach might be to allow the user to supply an XmlReaderFactory object.

Internally the change is reasonably manageable by exploiting the fact that we use the ActiveSource abstraction internally; we could introduce an implementation of ActiveSource (akin to SAXSource on Java) which wraps an XmlReader, and the API layer would merely have to wrap the supplied XmlReader in an ActiveSource and pass it down to existing internal interfaces.

Note, to support fn:parse-xml-fragment() we instantiate the XmlReader using

XmlTextReader reader = new(content, XmlNodeType.Element, 
                new XmlParserContext(null, null, null, XmlSpace.None));

Not sure how that differs...

In my understanding the XmlTextReader class is mainly a legacy from .NET 1.x, before the XmlReader.Create factory method was introduced. But for parsing from a string, like parse-xml-fragment does, its constructor taking that string as an argument is also a bit more convenient than creating an XmlReader over a StringReader over the content string.

I've added this (about a dozen lines of code -- plus rather more than that in unit tests!)

Great, thanks!