Project

Profile

Help

Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument?

Added by Martin Honnen about 3 years ago

On the .NET platform, the XML parser from Microsoft, based on the abstract XmlReader class, has always supported both parsing well-formed documents as well as external parsed entities, the latter by using an XmlReader created with XmlReader.Create(uri, new XmlReaderSettings() { ConformanceLevel = ConformanceLevel.Fragment }).

For both Saxon 10.6 .NET as well as SaxonCS 11 the DocumentBuilder API allows passing in an XmlReader to build a tree and as far as I have tested it works fine to use a "Fragment" reader like mentioned above to then run XPath 3.1, XQuery 3.1 or XSLT 3.0 against the document node containing not a well-formed XML document with a single root element but rather various top level nodes, for instance various top level elements.

I was wondering whether the same could be possible with XSLT 3.0 and streaming but as the ApplyTemplates method of Xslt30Transformer does not allow me to pass in an XmlReader it seems I am out of options.

Could such an overload public void ApplyTemplates(XmlReader input, IDestination destination) be added to the API?

For streaming XSLT 3 it might in some use cases be desirable to be able to process a stream of top level XML elements with an XmlReader and XmlReaderSettings with ConformanceLevel.Fragment.


Replies (5)

Please register to reply

RE: Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument? - Added by Michael Kay about 3 years ago

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.

RE: Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument? - Added by Michael Kay about 3 years ago

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

RE: Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument? - Added by Martin Honnen about 3 years ago

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.

RE: Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument? - Added by Michael Kay about 3 years ago

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

    (1-5/5)

    Please register to reply