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: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] Re: XSLTransform constructors are flawed
  • Date: Thu, 2 Sep 2004 13:02:58 -0700

On Sep 2, 2004, at 3:14 AM, Elliotte Rusty Harold wrote:

At 12:02 AM -0700 9/2/04, Wolfgang Hoschek wrote:

If that would work why can't the XSLTransform do the builder.build(source) internally, without breaking user code?

That is what it's doing now. The problem is it doesn't provide signatures for quite everything the Builder class does. In particular, it doesn't offer XSLTransform(InputStream, baseURL) and XSLTransform(Reader, baseURL) which Builder does offer. I could add these, but that would bloat the API further. It struck me on looking at these methods that they were minimal conveniences, and I prefer to avoid that.

Ok.



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?

API bloat and redundancy.

Yes, but it seems that if XSLTransform(InputStream) is potentially problematic, so is Builder(InputStream) as well. The problem is the same, or am I missing something here?


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.

That sounds like a separate issue, though one worth considering. I don't think I'll address it for 1.0, but I will add it to the list to be considered for future releases.

That would be most useful and welcome.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page