XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> There are currently five overloaded constructors in XSLTransform:
>
> public XSLTransform(Document stylesheet)
> public XSLTransform(File stylesheet)
> public XSLTransform(String stylesheetURL)
> public XSLTransform(InputStream stylesheet)
> public XSLTransform(Reader stylesheet)
>
> The last two are seriously flawed. :-(
>
> The specific problem is that they do not provide base URLs for the
> stylesheet, thereby preventing the resolution of relative URLs found
> in xsl:import and xsl:include elements and document() functions.
>
> There are several options open here:
>
> 1. Add new InputStream and reader constructors that take a second
> base URL argument
> 2. Deprecate the existing InputStream and reader constructors and
> them remove them.
> 3. Deprecate all but the first constructor and then remove them.
>
> I prefer the third option which would leave this class with just a
> single constructor. The other four constructors are minor
> conveniences at best. It's a simple matter of
>
> XSLTransform transform = new XSLTransform(builder.build(source));
>
> instead of
>
> XSLTransform transform = new XSLTransform(source);

If that would work why can't the XSLTransform do the 
builder.build(source) internally, without breaking user code?
I'm using the discussed methods but without xsl:import and xsl:include 
elements and document() functions so no problems here.

It might also be worthwhile to maintain some consistency between the 
signatures of Builder and XSLTransform, as long as they work as 
intended. Why provide some signatures in Builder and not for 
XSLTransform, and vice versa?

Perhaps another (fourth) option would be to add a XSLTransform(import 
javax.xml.transform.Templates) constructor similar in spirit to 
Builder(XMLReader). That way the other discussed methods could possibly 
go away, yet advanced/fully configured usage would become possible (for 
those who make sure that things works as intended in their context). 
Such stuff is needed to configure variables, functions and other 
transformer specific options. Currently the XOM XSLTransform really 
can't be used if such configuration is required by the app.

Wolfgang.

> However, since we're now in beta I do want to ask to what extent
> anyone's code depends on these four constructors? If anyone screams
> too loudly I'll consider retaining them, especially the File and
> String constructors since those aren't fundamentally flawed. At a
> minimum all will be deprecated for at least one beta before being
> removed. Thought? Comments?
> --


-----------------------------------------------------------------------
Wolfgang Hoschek                  |   email: whoschek AT lbl.gov
Distributed Systems Department    |   phone: (415)-533-7610
Berkeley Laboratory               |   http://dsd.lbl.gov/~hoschek/
-----------------------------------------------------------------------