>> Xerces chooses to report them as soon as an error condition has been found. << But in this case, it seems Xerces found the error before parse the empty tag.
Benson. -----Original Message----- From: Michael Glavassevich [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 8:52 AM To: '[EMAIL PROTECTED]' Subject: RE: Empty tag handling question On Mon, 25 Aug 2003, Paul Norris wrote: > It might be worth your while putting in a feature request at Bugzilla. > Turning around the timing of events would be very difficult and you're > not likely to get it. But having more information in the > SAXParseException about the context of the error would help you with > deciding where the error belongs is much easier and might get into a > future release. > > Cheers, > Paul. Hi all, I think reliance on error event order is unwise. As far as I can tell, there's nothing that constrains when a parser reports non-fatal errors. Xerces chooses to report them as soon as an error condition has been found. Some other hypothetical parser might decide to buffer all errors it discovers during validation, and then report them later, or emit these events in some other order you weren't hoping for. So even if Xerces changes its behaviour, other parsers may exhibit other behaviour. In short, your SAX code won't be implementation independent. Adding more text in the SAXParseException will not make it easier to programatically determine the context of errors. Besides varying between locales, these messages will vary between parsers. If there's interest by SAX users for this richer form of error reporting, then they should open a feature request for SAX (http://sax.sourceforge.net). If you have a look at the javadocs on the SAX website, it seems that an effort has started to provide more information in SAXParseExceptions (http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#excep tions). The new feature for SAX 2.1(?) would provide URIs with the SAXParseException, that identify the type of error encountered. This doesn't provide the context of the error, but at least it allows a user to programatically determine which constraints were violated, which would be a great improvement over the current behaviour. -------------------- Michael Glavassevich [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
