DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2213>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2213 Callback order PATCH [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Enhancement Priority|High |Medium ------- Additional Comments From [EMAIL PROTECTED] 2001-11-20 10:49 ------- Personally, I find the direction of all of this wrong-headed. The real problem is that there is no "startOfMarkup" event that is called before you ever touch the inside of the markup declarations. startAttlist is being picked on here because it is poorly named and is trying to be clever in only reporting the element name once when an attlistdecl contains several attdefs. The reason that you cannot come up with a fix for all cases is that you are misusing the startAttlist event for a purpose that it was never intended to serve. I can come up with many others cases that haven't even been mentioned for attlist decls and the others that would also fail. While I feel that it is unfortunate that we have been adding support for a "feature" that may slow down the common case, that particular cat is out of the bag. So we should either commit to supporting this nested event reporting within markup or we shouldn't. If we are going to support it, then there need to be "reliable" events to indicate when PE references are used within markup. I have restored the priority of the bug and changed it to an enhancement request. This may be taken by some people the wrong way, but the reality is that the system was not designed to support the "feature" that is reported to be defective. Any evidence to the contrary aside, you have just been getting lucky so far. To stretch an analogy, you can pound screws into boards with a hammer all that you want, and might like and/or desire the results you achieve, but that doesn't make the hammer a screwdriver. Let's take this discussion to the mailing list, reach some conclusion/consensus, and design some proper support for the "feature" if that is what we decide we want to do. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
