XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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.