>FYI, I've managed to track down and eliminate the bugs in my code >that were causing this and several other exceptions deep inside >Xalan. My comment about the incorrect JavaDoc still stands, though. Yeah, cut-and-paste errors. At some point, in someone's Copious Spare Time, a real review of the Javadoc would be a good thing; there's plenty of room for improvement. >Xalan is not particularly robust against a misbehaving SAX XMLReader >... >it might be worth somebody's time to figure out how to harden >Xalan against these sorts of attacks, whether malicious or unintentional. There's a trade-off here: Hardening (at least to the point of making errors more diagnostically useful) does cost some CPU cycles. I *think* we could afford it... but I think we'd want to be careful about designing it efficiently. My own inclination is actually to say that the hardening layer ought ot be a SAXFilter itself, which would be plugged in when folks don't trust their XMLReader and left out when you know you're working with one that is robust. The overhead of a filter is a bit higher than a built-in check, but this would let us continue to avoid overhead when not needed. And a hardening SAXFilter would be a usefully reusable chunk of code. Beware of trying to build every possible feature into a single codebase. ______________________________________ Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
