XOM API for Processing XML with Java

[Adam Constabaris <adamc AT unc.edu>]

John Cowan wrote:
> Elliotte Harold scripsit:
>
> > Yes, this sort of non-fatal error is an especial pain for XOM because
> > it has no non-fatal errors. The only thing it does to report an error
> > is throw an exception. There's no ErrorHandler as in SAX, nor does
> > XOM have any other means of talking to the end user.
>
> If xml:id errors were marked "fatal", then *every* implementation would
> have to treat them as fatal.  However, there is nothing stopping XOM from
> (a) treating the errors as fatal in every case, or (b) providing a switch
> the user can set to "Ignore xml:id errors" or "Treat xml:id errors as
> fatal", or (c) providing a hook such that elements with xml:id errors
> are passed to the hook, or ....

I think I'm with John on this, and I came across a similar sort of issue 
recently in relation to a library that throws exceptions even if it can 
successfully (for some relevant definition of that term) produce output. 


There's already an example of the kind of behavior described here in 
XOM, in the ValidityException.getDocument() method, which strikes me as 
a reasonable compromise: failure to validate is an exception condition, 
but there could still be a well-formed document that could be processed.

It's pretty important here in the ValidityException case that you have 
to turn on validation explicitly in your parser to get the exception, 
though.  The analogy, I believe, would be to add a 
"setStrictXMLIDCheck()" (or whatever) option in Builder.