I appreciate that there are inconveniences, but if you're just looking for backwards compatibility, the changes should be, for the most part, fairly minor.
I'm sorry we haven't been able to convince you of the benefits of the changes, that's on me as the lead on this. I'm not sure really what else I can do to convince you, if you have specific concerns that we could address then I'd be happy to see if we can come to some sort of compromise. You talk about a java.xml.transform.URIResolver interface, are there any other things you'd like to see? On 26 July 2012 17:15, Jeremias Maerki <[email protected]> wrote: > That's not quite true. That worked perfectly before by setting your own > JAXP URIResolver. You could even resolve a URI to a DOMSource (or > SAXSource) containing an SVG image that you've dynamically built based > on some data (think charts). With the new approach, you have to > serialize that XML to a stream (buffered in memory or on disk) which > costs performance. Not a very common use case, I know, but we're talking > possibilities that are going away with the API changes. > > Previously, you could use Apache XML Commons Resolver for XML catalog > functionality. Now you probably have to write an adapter from > URIResolver to ResourceResolver (haven't had time to try that, yet). A > convenience adapter is missing. > > > Jeremias Maerki > > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote: > <snip/> > > Btw... it's really nice that all data is loaded now through the new URI > > resolver. In the near future I'd like to use a custom scheme (e.g. > > myscheme://imageid) in order to load images instead of using HTTP. That > > wouldn't be possible without your change. So thanks! > <snip/> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
