XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT ibiblio.org>]

On Thu, Sep 16, 2010 at 3:01 PM, Dmitry Katsubo <dma_k AT mail.ru> wrote:
> Dear XOM developers!
, which may differ from majority's:
>

XOM is designed quite explicitly not to do everything in every
possible way. I find that adding every possible variation of a given
operation simply makes an API too confusing, hard to learn, and hard
to use. New methods are added only if they have a compelling
justification; i.e. if they add functionality that does not already
exist.

> * Having XSLTransform(Source source) constructor private is too
> restrictive. One may wish to pass XSLT template as InputStream without
> pre-building it as XOM document model. I don't see any good reason, why
> there is only nu.xom.Document constructor.

There might be some justification for doing this, but it's not
self-evident. The existing code does not reparse the document, and
something's going to have to parse it at some point.  You'd have to
show there was a significant amount of overhead to building the XSL
document as a XOM tree.

> * It looks like XSLTransform class itself has only one added value:
> handling of exceptions. More over in this very example XOM is throwing
> checked exception while in the rest of the library unchecked are preferred.
>
> * Having XOMResult/XOMSource classes public adds flexibility to XOM, as
> one can use them separately from XSLTransform.

No, you can't. The Source and Result interfaces are not properly
designed for reuse. Not a lot I can do about that. For that matter,
neither are XOMResult and XOMSource, but that's a deliberate decision
and why they are private.

> * Returning Nodes as result of transformation is a bit odd (I took
> extract from tutorial [1]):
>
> Nodes output = transform.transform(input);
> Document result = XSLTransform.toDocument(output);
>
> I fully agree that result should be a list of nodes, but I think
> returning DocumentFragment better matches the return result type. Maybe
> it wouldn't be simple then...

There is no DocumentFragment type in XOM. Why would you need it when
you have Nodes?

-- 
Elliotte Rusty Harold
elharo AT ibiblio.org