> If the change is not made, we run the risk of having code that currently > works outside of Apache SOAP not work within Apache SOAP, which would be a > > very bad thing. What's the easiest thing to do? I'm sure providing a
First of all, if someone's using DOM2Writer from Apache SOAP then that's not code that's independent of Apache SOAP. If someone's creating an incorrect DOM tree then you cannot blame a downstream processor that does the right thing for the broken results!! > simple workaround like what I've done here is much better than telling > users to bugger off and write "proper" code; especially when doing so > would have an impact on products already on the market. Sorry, that's not acceptable in my book. We've had cases before where there were bugs in specific Xerces version which made Apache SOAP break. We did not go about making "bug-compatible" changes to do cover that; rather, we reported the bug and waited for them to fix it. The same has to apply for XSS (and whoever else); if its a bug in their code then Apache SOAP will not work with that buggy version of their code. > But, if you still disagree, I recommend that we put it to a vote. Well, if it must, fine. I'm -1'ing it for sure. Also, I recommend that we only take votes from people who've been participating in the development say in the last 6 months. I know there are 10+ "sleeper" committers; having them +1 and having that count is meaningless, at least to me. I'm sure someone'll throw the process book at me now. Sanjiva.
