> > Re what to do ... changing the default behavior of a SAX2 parser isn't > > something that could be done while retaining backwards compatibility. > > I don't think adopting this change will break backwards compatibility: > the information that users get today will remain unchanged.
The original Xerces bug report identified a backwards-incompatibility: different values reported for "xmlns" and "xmlns:*" attribute values. Even wrote that the empty string was preferred, as I recall ... that's "information that users get today". How can you claim that? The change would be backwards-incompatible to every SAX2 driver. It would instantly make conformant ones be nonconformant. (Nothing in SAX2 r2 does that!!) And there's really no way to evaluate the knock-on impact to the application layers -- it's fairly certain that some stable infrastructure would break in a hard-to-diagnose way. That kind of minor incompatibility is actually worse to deal with than a major incompatibility, since most things still work. Creating such minor system breakage is like having a low level infection: things just stop being as good as they were, and it's often never cured. It's really not so hard for layers to tweak this, when they need to. > I believe that it is better to try to expose consistent information ... Me too, but when W3C causes such problems by changing their own specifications to create internal inconsistencies, "better" is the wrong game to play. A better one is "stable". (Sigh.) I think that what I'll do for now is update the SAX2 docs to identify this case. It's not a widely recognized issue. - Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
