XOM API for Processing XML with Java

[Axel von Engel <a.vonengel AT gmail.com>]

Hi Elliotte,

While preparing that example repository, I managed to avoid the problem
mentioned earlier. I previously got Exceptions from XOM when I tried to use
XSLTransform, and avoid the SAX API altogether. Turns out I ran into this
info from your Tutorial:
> XSLTransform includes a static toDocument utility method that converts a
Nodes object into a Document object. However, if the Nodes passed to this
method contains no elements, more than one element, or any Text objects,
then toDocument throws an XMLException.

I was using toDocument after each successive XSLTransform, and apparently
the first transformation resulted in the following Nodes: [Text,
ProcessingInstruction, Text, Element]. Where each of the Text objects just
printed as a line-break.

I now got some pretty neat code that does the transformation just as I want
- just passing on the Nodes. Your API is much easier to work with than the
SAXTransformer one :)

If you're interested in what I meant with the SAXConverter xml:base strip
problem, take a look at https://github.com/avonengel/xom-sax-help. The code
is a bit messy, though. I couldn't quite bring up the motivation to clean
it up, as I now solved my initial problem:

This test fails:
https://github.com/avonengel/xom-sax-help/blob/master/src/test/java/com/github/avonengel/xomsaxhelp/XslFoTest.java#L99
This test
https://github.com/avonengel/xom-sax-help/blob/master/src/test/java/com/github/avonengel/xomsaxhelp/XslFoTest.java#L70
uses
a hacky workaround:
https://github.com/avonengel/xom-sax-help/blob/master/src/main/java/com/github/avonengel/xomsaxhelp/XslFo.java#L206-L211


So basically SAXConverter may fail subsequent transformations, if they rely
on xml:base attributes to be present. If I understood correctly, using
SAXConverter to apply additional XSLT should not be necessary, though.

Cheers
Axel



Am So., 5. Mai 2019 um 14:20 Uhr schrieb Elliotte Rusty Harold <
elharo AT ibiblio.org>:

> If you can boil this down to a simple example that doesn't use the
> actual data that would be even better. What I need is the bare minimum
> to show:
>
> 1. What you expect to happen.
> 2. What is happening.
>
> From that I can determine if this is a bug or WAI.
>
>
>
>
> On Sun, May 5, 2019 at 6:54 AM Axel von Engel <a.vonengel AT gmail.com>
> wrote:
> >
> > Thanks for the quick response. I tried to keep the initial mail short,
> but
> > apparently that was too short ;)
> >
> > I'll prepare a repo with an example, but it will take me a couple of days
> > at least. I might not be able to show the XSL Transformation error I
> > mentioned, though. I can't publish the involved stylesheets without
> > approval from the company, and that will probably take ages.
> >
> > Am Sa., 4. Mai 2019 um 01:10 Uhr schrieb Elliotte Rusty Harold <
> > elharo AT ibiblio.org>:
> >
> > > Interesting. It's hard to follow all that without an example though so
> > > I'm not sure whether XOM is doing something wrong or what. If you
> > > could bundle this into a self-contained example, or best of all, a
> > > unit test, I could take a look.
> > >
> > > On Fri, May 3, 2019 at 3:44 PM Axel von Engel <a.vonengel AT gmail.com>
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > (This got a bit long, see last paragraph for TL;DR)
> > > >
> > > > I recently started to work on migrating a DocBook toolchain to a
> Gradle
> > > > plugin, and was looking into doing all the transformations via SAX in
> > > Java.
> > > > The pre-existing toolchain at the company uses a variety of pre- and
> > > > post-processing XSL stylesheets, and even used different processors
> for
> > > > those.
> > > >
> > > > My first approach was the following:
> > > > 1. Parse the source via Xerces
> > > > 2. Construct a TransformerHandler backed by Saxon for each of the
> > > > stylesheets
> > > > 3. Use a FOP renderer as the final SAX ContentHandler to create PDF
> > > output
> > > >
> > > > This worked pretty well, until I ran into this lovely Xerces issue:
> > > > https://issues.apache.org/jira/browse/XERCESJ-1102
> > > > So basically, nested xi:include tags result in wrong xml:base
> attributes,
> > > > leading to wrong relative image paths.
> > > >
> > > > Through some searching, I found XOM, and used that on top of Xerces:
> > > >
> > > > SAXParserFactory parserFactory =
> > > >
> > >
> SAXParserFactory.newInstance("org.apache.xerces.jaxp.SAXParserFactoryImpl",
> > > > classloader);
> > > > // disable xInclude on the Xerces parser
> > > > parserFactory.setXIncludeAware(false);
> > > > // more config ...
> > > > XMLReader xmlReader = parserFactory.newSAXParser().getXMLReader();
> > > >
> > > > Builder parser = new Builder(xmlReader);
> > > > Document input = parser.build(rootDocbookFile);
> > > >
> > > > input = XIncluder.resolve(input, parser);
> > > >
> > > > // handler creation omitted:
> > > > SAXConverter saxConverter = new SAXConverter(handler);
> > > > saxConverter.convert(input);
> > > >
> > > > The problem with this approach: the SAXConverter does not emit
> xml:base
> > > > attributes. I later found this in the sources:
> > > >
> > >
> https://github.com/elharo/xom/blob/master/src/nu/xom/converters/SAXConverter.java#L98
> > > > Which led to my current workaround hack: Use reflection to set
> > > > SAXConverter.stripBaseAttributes = true
> > > >
> > > > Another approach I tried was to use XOM to do the XSL transformations
> > > > instead of using the SAX API. This resulted in some errors that said
> > > > something like "can't insert Text into Document" without any
> meaningful
> > > > hints at which XSL template might have caused it, so I didn't
> investigate
> > > > further.
> > > >
> > > > All in all, I feel this is a hack, and find it hard to believe there
> is
> > > no
> > > > cleaner solution. Google and Stackoverflow didn't turn up much else,
> > > though.
> > > >
> > > > TL;DR: My root issue is with Xerces: it can't properly resolve nested
> > > > xi:include tags.
> > > > Does someone know another solution to parse the XML, and resolve the
> > > > xi:include tags correctly?
> > > > Is there some way to debug what causes XOM to error during XSLT?
> > > > Or maybe there is another way to get the results from XOM to the SAX
> API
> > > > (including xml:base attributes, and without writing to disk)?
> > > >
> > > > Best regards
> > > > Axel von Engel
> > > > _______________________________________________
> > > > XOM-interest mailing list
> > > > XOM-interest AT lists.ibiblio.org
> > > > https://lists.ibiblio.org/mailman/listinfo/xom-interest
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo AT ibiblio.org
> > > _______________________________________________
> > > XOM-interest mailing list
> > > XOM-interest AT lists.ibiblio.org
> > > https://lists.ibiblio.org/mailman/listinfo/xom-interest
> > >
> > _______________________________________________
> > XOM-interest mailing list
> > XOM-interest AT lists.ibiblio.org
> > https://lists.ibiblio.org/mailman/listinfo/xom-interest
>
>
>
> --
> Elliotte Rusty Harold
> elharo AT ibiblio.org
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> https://lists.ibiblio.org/mailman/listinfo/xom-interest
>