Re: [xsl] Is a Java program more likely to succeed in creating an in-memory representation of the input XML than an XSLT processor?

["Martin Honnen martin.honnen@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On 08/05/2024 13:28, Roger L Costello costello@xxxxxxxxx wrote:
> A (non-streaming) XSLT processor creates an in-memory representation of the
input XML document. Right?
>
> Sometimes the input XML document is large and when the XSLT processor tries
to create an in-memory representation of the input XML document, an
OutOfMemoryError results.
>
> Alternatively, the input XML document may be read into an in-memory
representation in a Java program.
>
> Is a Java program more likely to succeed in creating an in-memory
representation of the input document than an XSLT processor? Is the Java
program less likely to fail with an OutOfMemoryError?

There lots of tree models in the Java world, DOM, JDOM (in several
variants/versions), XOM, to name only some, the memory consumption will
depend on the tree model I think.

So I am not sure there will be a general answer, the usual advantage of
XSLT/XPath tree models is that they only need to allow read access while
most other tree models like DOM/JDOM/XOM will provide read and write
access and that way might be more complicated, not sure whether that
directly relates to a higher memory consumption.

And an advanced XSLT processor like Saxon doesn't restrict you to a
single tree model, I think Saxon itself has various native ones like
TinyTree and LinkedTree and supports running XSLT against most popular
third party tree models as well.

In the end you would need to measure memory use for a particular use case.