Re: Unwanted SAXParseException

David Brownell <[email protected]> writes:

> Arnaud Vandyck wrote:
> > On Sat, 18 Oct 2003 08:21:35 -0700
> > David Brownell <[email protected]> wrote:
> > 
> > 
> >>That's part of the reason why the SAX spec has long said specifically:
> >>"An InputSource object belongs to the application: the SAX parser
> >>shall never modify it in any way...".  (Which is what your patch
> >>makes it do...)
> >>
> >>The right fix in this case is to your Resolver implementation,
> >>not any parser, since any parser change is likely to break some
> >>other application.
> > 
> > 
> > Ito's  patch makes  gnujaxp  result  closer to  Sun's  and Apache's  sax
> > parser, isn't it? 
> 
> I think IBM's original Apache code resolved against the current
> file system directory (instead of just failing) ... breakage
> that's obvious in environments without file systems, or parsers
> that don't require java.io.File etc (like AElfred2).
> 
> It was more subtly broken when the base URI should have been some
> http://... URI, or a different directory.  Apache folk weren't much
> into bugfixing back when such bugs were first reported to them.
> I'm pretty sure that Sun's original code didn't have such bugs.
> 
> That is, I think Ito's patch uses a different heuristic.  In the
> case of this example, they'd act the same -- due to the specific
> URIs in use.  But not in all cases, so it's not necessarily
> going to be "closer" except in simple cases.
> 
> 
> The basic issue is that applying _any_ heuristic at that level
> is going to fail badly in some cases.  Throwing an exception is
> at least an indication that the inputs were bad.  And AElfred2
> was at least reporting a warning about what was wrong, before
> throwing the exception.

In situations like this I always think that some sort of switchable
property system works well.

For example the excpetion throw checks a property to test whether the
behaviour should be "strict" or not. 

"Strictness" implies not doing things that *might* be helpful to the
user.

The fact that we've had a query from a user might imply that we're
not being as helpful in this situation as we might be. So it might be
a good idea to add something switchable for this.


Nic