Vidar Ramdal schrieb: > On Fri, Feb 13, 2009 at 6:22 PM, Vidar Ramdal <[email protected]> wrote: >> One easy way to get extensible format support, at least when speaking >> of XML formats, is to let XmlReader look for a reference to an XSL >> stylesheet in the XML file (<?xml-stylesheet type="text/xsl" >> href="stylesheet.xsl"?>). > > I've come really close to implementing this, but I have hit a wall > when it comes to resolving the location of the XSL. > In the example above, one would consider "stylesheet.xsl" to be a > relative path to the XSL - relative from the XML file. > However, I can't make XmlReader resolve the XSL file, as XmlReader > only gets an InputStream of the XML, which contains no information on > the XML's location. > > One option would be to change > o.a.s.j.c.i.ContentReader#parse(InputStream, ContentCreator) to > parse(URL, ContentCreator). > This would mean making ContentReaders responsible for opening and > closing the InputStream from the URL. > It seems that every caller of ContentReader.parse knows the URL of the > inputstream it is passing to the ContentReader, so that should not be > too much work.
+1 to this change. It makes perfect sense. > > Another option would be to only support absolute URLs when refering to > the XSL file. This works in my current implementation, as long as the > XSL is not located in a bundle. > But in many cases the XSL *would* be supplied in a bundle, I believe > bundle resources can be addressed by bundle://bundle-id/etc, but I > don't know the bundle ID before the bundle is installed, right? > > Any suggestions? Lets go with the ContentReader API change you propose. It is not exported from the bundle so we are free to adapt it as we need. Regards Felix
