I have yet to look at this more closely, but I have the impression that it would not be the right approach to do URI resolution in the ParsedURL area, but it should actually occur beforehand. As the name suggests ParsedURL's job is to parse and provide access to a URL. A URI is a more general concept and URI resolution should probably happen before ParsedURL goes into action. ParsedURL is a very intriguing concept to at least partly replace java.net.URL. That's why I'd like ParsedURL to end up in XML Graphics Commons if possible (FOP would profit). But it is a lower-level concern/facility than URI resolution. So I'd instinctively do URI resolution in a different area, so that a URIResolver could be provided as a transcoding hint (i.e. non-global). I hope I can have a closer look later.
On 16.08.2005 12:28:09 Thomas DeWeese wrote: > Hi all, > > > On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote: > > >>This is actually not about relative paths, but actual URI resolution. > >>If you look at the JUnit test case I committed earlier [1] I use the > >>URIResolver to resolve an URI "funky:myimage123" to one of the bgimg > >>bitmaps in our test directory (a file URL). That's how people can > >>specify abstract URIs instead of concrete URLs to point to resources > >>whose location is not known at deployment time. And it's where XML > >>Commons Resolver jumps in to provide a widely used mapping from URIs > >>to URLs. > >> > >>[1] http://svn.apache.org/viewcvs?rev=232788&view=rev > > Manuel Mall wrote: > > > Alright, this means we need to set the FOP resolver on the SVG > > processor. Not sure if Batik supports the > > javax.xml.transform.URIResolver interface. May be any Batik people > > lurking on this list can shed more light on this? > > All Batik URL resolution is handled by our ParsedURL > implementation. The only 'problem' with the ParsedURL class > is that it doesn't have a very direct connection to a UserAgent, > so configuration is done on a per JVM (really classloader) basis. > So it would be simple to add support for URIResolver in ParsedURL > but it wouldn't be a parameter on the 'batik.transcode.Transcoder' > class it would be global. I'm not sure if this is a problem > or not (I didn't follow all of the discussion above). > > There is also the potential issue of dragging in a new > dependency for an interface with a single method that only > takes/returns primitive types. ;) Jeremias Maerki
