Elena Litani writes: > I don't think adopting this change will break backwards > compatibility: the information that users get today will remain > unchanged. We will provide one additional piece of information - > namespace for namespace attributes and I don't see how this may > break users code... ?
Wrong. There's no such thing as a backwards-compatible change to an API: either you break the drivers or you break the clients. In this case, clients that expect the old behaviour will probably be OK (they're unlikely to rely on the Namespace URI being null), but clients that expect the new behaviour will break on SAX drivers that implement the old behaviour. This will be a typical bug report: I'm using the ACME Java game development kit, and it requires a SAX2 parser. I installed the FooBar parser, which says it is SAX2-conformant, and now I get a NullPointerException. Can anyone help? > I believe that it is better to try to expose consistent information > via different APIs (e.g. DOM/SAX). I think that's a worthy goal (that's why I pushed the W3C to create the Infoset WG in the first place) but denying the costs isn't the right way to get there. You have to start by acknowledging that this is a major change that will break all existing SAX2 *drivers*, and then decide if (or when) the benefits of making the change will outweigh the costs. All the best, David -- David Megginson [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
