URI resolving

[Joerg Pietschmann <jo...@zkb.ch>]

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: URI resolving

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Comments below.

-----Original Message-----
From: Joerg Pietschmann [mailto:joerg.pietschmann@zkb.ch]
Sent: March 18, 2002 12:09 PM
To: FOP Dev
Subject: URI resolving

[ SNIP ]

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).

[ SNIP ]

-----End of Original Message-----

Hi, Joerg

I snipped out the part that dealt with URI resolution; this is obviously
important, but since we have a 2-part problem - WHERE is the image and WHAT
is it - I'd rather deal with the WHAT first. Which is why I presently
addressing the above comments of yours.

However FOP does it now, all I know is that I personally distrust external
information - content-types and what have you. Let's keep in mind that
although we are using URI terminology a lot of these are going to be file:
URLs and the path of the file is going to be just about all we have to work
with. The file extension is reliable enough that it can be used for a first
guess but that is about it. But my current thought process is that FOP
doesn't worry about the WHAT at all - that's what the image library is for.

I came across this excellent list that Marco Schmidt has created:
http://www.geocities.com/marcoschmidt.geo/java-image-coding.html. Seems to
me that with this embarrassment of image-library riches all we should have
to do is define a simple interface that image readers must follow, and that
we then can write adapters that target some of the more useful libraries, as
required. From my viewpoint we'd be doing a good job if we can write
FOP-side code that doesn't even know what a JPEG or PNG or WMF or anything
else is. If the library of choice can't tell us that much, nor tell us about
the basic geometry that we need for layout, then what good is it?

This may turn out to be too simplistic and naive but I hold it up as a
desirable target. I have to research libraries that are available, and do
some coding and testing, to see if I am just talking through my hat, but I'd
sure like to see a situation where format-specific FOP classes disappear.

URI resolution is another matter. I haven't put any thought into it, other
than having read your comments. The one thing I'd mention right now is that
we need to look at how the available libraries expect to see image input.
Again, if most of the otherwise useful ones tend to fall short in this area
then we can always write adapters - which can be the same classes as the
adapters mentioned above.

Regards,
Arved Sandstrom


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org