XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

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.

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

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

--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Effective XML (Addison-Wesley, 2003)
  http://www.cafeconleche.org/books/effectivexml
  http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA