Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument?
Added by Martin Honnen over 2 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 over 2 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 over 2 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 over 2 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 over 2 years ago
I've added this (about a dozen lines of code -- plus rather more than that in unit tests!)
RE: Could an overload of ApplyTemplates method of SaxonCS take an XmlReader as the first argument?
-
Added by Martin Honnen over 2 years ago
Great, thanks!
Please register to reply