Hi,
i did some thinking about FOP interfaces and especially
the URI resolving problem last weekend.
In JAXP you can do some rather geeky things with the
URIResolver:
- implement caches
- implement URL redirections
- implement your own protocols for synthetic XML
As an example for the latter, use a "filelist:/foo/bar"
URL to produce a directory listing XML like
<filelist>
<file>baz</file>
...
by looping over File("/foo/bar").list() and fire SAX events.
This way you can XMLify all kind of odd external data and
pump it into the transformation process without bothering
with temporary files. This is possible because the URI resolving
method returns a javax.transform.Source, you can provide
your own implementation for an XMLReader and a sax.InputSource
and put them into a javax.xml.transform.sax.SAXInputSource
to get the effect described above (a more elaborate description
is in the XSL list archive).
In FOP, unfortunately, we have to deal with both XML sources
mainly for SVG and binary sources for most other formats. Well,
there's also PostScript which is a sort of character source.
It would be interesting to keep the possibility for dynamically
creating SVG or other XML based formats out of thin air by
directly firing SAX events or by providing a DOM tree, while
also having the ability to deal with non-XML formats.
One solution could be a delegation model
class XMLURIResolver {
XMLURIResolver(BinaryStreamURIResolver bsur) {
theBinaryStreamURIResolver=bsur;
}
Source resolve(String baseURI,String relURI) {
return new SAXSource(getXMLReader(),
theBinaryStreamURIResolver.resolve(baseURI,relURI))
}
}
The fo:externalGraphics handling code would somehow have to decide
whether the graphics is XML and invoke theXMLURIResolver.resolve(),
otherwise call theBinaryStreamURIResolver.resolve() directly. (It
may be an idea to provide an additional layer for character sources
like PostScript)
I'm not quite sure how FOP decides how to handle a certain input
for an external-graphic, i have faint memories that it first looks
at the content-type attribute and if there is none, it tries to
guess a content type from the URL. It may be an idea to give the
user hooks for this two mappings as well (content-type -> content
handler and URL -> content type).
Does this sound reasonable?
It would be interesting to see how JAXP will deal with XSLT 2.0,
there is also the possibility to import non-XML data.
There is another point: JAXP uses a factory pattern where the
factory creates a transformer for a single use holding the
compiled style sheet. The factory uses an URIResolver for resolving
URIs encoutered in xsl:include and xsl:import elements in the style
sheet. A transformer inherits the URIResolver form the factory, but
it is possible to set another URIResolver for resolving URIs
encountered during transformation.
In FOP, the analogs are resolving URIs which are part of the
configuration, like URIs pointig to font descriptions, and do not
depend on the FO input, and URIs which are encountered while
processing FO input. There are some arguments in favor of splitting
resolving responsibilities in FOP in a similar way, in particular if
a similar factory/processor pattern is choosen for the FOP API.
The advantage of such a pattern would be that the factory instance
could efficiently cache configuration data while still having a
convenient way to override particular settings for individual
processor runs.
Regards
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
