Bug #6187
closed
Why is StandardUnparsedTextResolver so insistant that a streaming source be returned?
0%
Description
We call the resolver, which can return a Source but we
throw new XPathException("Resolver for unparsed-text() returned non-StreamSource");
if it doesn't get back some flavor of StreamSource.
This seems unreasonable. Consider, for example, the case where this resolves through the XMLResolver. The resolver doesn't return a stream source, it returns a plain old source.
Updated by Michael Kay 8 months ago
Well, other kinds of Source deliver representations of XML documents, and we're looking here for plain text.
Updated by Norm Tovey-Walsh 8 months ago
Yes, I see that. And previously the API required a Reader.
Maybe the bug is in the XML Resolver. If you wind your way through the APIs, given a URI, a nature, and a purpose, you eventually wind up at org.xmlresolver.NamespaceResolver which defines:
public Source resolveNamespace(String uri, String nature, String purpose) throws TransformerException;
For a nature of text/plain, Source is wrong.
There's also been a request to expose more of the information that the resolver knows about the resource (including the nature and purpose in the response, for example). Perhaps there should be a different API that returns something more general.
What's one more URI-related API between friends?
Updated by Norm Tovey-Walsh 8 months ago
Sketch for an improved resolver API: https://so.nwalsh.com/2023/08/29-xmlresolver
Updated by Norm Tovey-Walsh 6 months ago
- Status changed from New to Closed
This will be addressed by an improved XML Resolver release. Using the Source API for non-XML resources is just...wrong.
Please register to edit this issue
.