<delurk> "Be strict in what you send, but liberal in what you receive."
I don't see any problem with checking in the new fixed version which deals better, except perhaps that as Sanjiva says, we're letting them do the wrong thing and there's a valid POV which says the sooner they learn that it's wrong, the better. I'm assuming that we have precisely the same issue in Axis, since we lifted the DOM2Writer from SOAP 2.2. My suggestion is that we make the change, but in the cases where the incorrectly defined attributes are found, we log a big loud warning message (via log4j in Axis, via System.err.println() in SOAP 2.2) and then do the lenient thing. Indeed, guys, some good discussion here! --Glen </delurk> ----- Original Message ----- From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 28, 2001 9:38 PM Subject: Re: Bug with DOM2Writer > > A plea for sanity here: my own personal belief is that the correct > behavior > > of code when receiving invalid input is undefined. So, let me turn the > > question around: why is the current behavior which produces not well > formed > > output preferred over one that does? > > My opinion only: Because it forces the offending programmer to > understand his/her mistake and do the right thing. As James has > pointed out even some "tutorials" out there have the incorrect > instructions on DOM and namespace handling. Its no doubt > complicated and painful (ask Matt, he'll tell you), but it does > work correctly. So IMO we're not doing anyone a favor by letting > them believe that they're doing the right thing when they're not. > So we can fix Apache SOAP (in a nightly build). But next time > around these offending programmers are going to say some other > DOM application is wrong. > > So that's the rationale for the principle. Given all that, I can > still live with committing this change *iff* its pretty clear that > it won't break other stuff. The current version still won't do > that, I believe. > > Sanjiva. >
