> So I guess the answer to your question is that your resolver will get > http://www.w3.org/TR/xslt#document and it's up to your code to "do the > right thing."
That's good. I was worried that custom protocols, which have non-standard base/reference combining rules, could not be supported. > Well, one thing we could do is add the ability to the URI resolver to > send events to a SAX handler, if one is supplied, rather than return > an instance of a document. This goes beyond my proposal. I was happy generating InputSource objects. > So, I get what I'm saying is let's consider something like this: [API snipped] Shouldn't there at least be an option to return an InputSource? > Because the "source" of the data is not a stream of bytes addressable > by a URL, so the parser has nothing to parse. Remember, an > EntityResolver must return an InputSource, which pretty much means a > stream of bytes to feed the parser. Consider the case where the > user wants to construct a document on-the-fly in response to a URI. > For example, imagine a custom URI scheme that specifies a SQL query > where the result set is used to create a document. OK, we are expanding the API in two directions then: 1. Allow the user to do their own URI munging 2. Allow the user to do create custom documents using many types I can't really comment on the utility of (2) since I don't need that functionality. I think that (1) is necessary unless more work is added to Xalan to get custom schemes right. As an aside, Cheers, Brian
