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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
