XOM API for Processing XML with Java

[<nu.xom AT io7m.com>]

'Lo.

On 2016-06-01T12:34:15 -0700
Elliotte Rusty Harold <elharo AT ibiblio.org> wrote:

> It's not quite that simple. There's a significant cost in API complexity
> (especially since you have methods that don't work unless you know the
> magic incantation) and even if you don't ask for it, there's still an extra
> reference per object being stored.

I'm not sure which methods you're referring to here. Unless I've
misunderstood what Michael was describing, the existing Node types
would not be changed at all. What I was picturing was a way to enable
storing of lexical information via the Builder type, with a method on
the Builder that returns a (possibly empty) map of Nodes to Positions
after parsing.

There's almost certainly implementation complexity that I've not
commented on or fully examined, but it doesn't seem like this should
affect the complexity of the user-facing API, or entail adding a
new reference field to each node type (if that's what you were
referring to).

If you don't ask for lexical information, the cost should be comparable
to storing a single empty per-builder identity hash map.

This is actually what I'd already be implementing outside of the XOM
API if there was a way to intercept the information without modifying
XOM.

M