Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] Re: XSLTransform constructors are flawed

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: xom-interest AT lists.ibiblio.org
  • Cc: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Subject: [XOM-interest] Re: XSLTransform constructors are flawed
  • Date: Thu, 2 Sep 2004 00:02:09 -0700


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/
-----------------------------------------------------------------------





Archive powered by MHonArc 2.6.24.

Top of Page