Hi,
I may be taking a naive view here, so please excuse
me if I'm making you roll your eyes, but isn't this
just the kind of thing API versioning is for? If SAX2
as specified requires applications to expect empty
instead of null, then that's that and we can grumble
about it all we want, but if you change it, it just
has to be in a different version, SAX2.1 or SAX3 or
whatever. As long as the definition of each version
of the API is clear, then SAX2 drivers behave well
with SAX2 apps, and SAX3 drivers behave well with
SAX3 apps.
SAX1 apps weren't compatible with SAX2 drivers either
(different interface name altogether), so there is
precedent for completely non-backwards-compatible API
changes here. And I guess it's not just limited to
new major versions, since David maintains there's no
such thing as a backwards-compatible API change at
all, minor or major (unless minor versions are only
supposed to be documentation fixes only?)
I understand that rolling out a new major version of
SAX is not something you do at the drop of a hat :)
but SAX2 still isn't conceived of as "final" anyway,
is it? So if other changes are made, then this change
can be made at the same time, since *any* change is
going to be non-backwards-compatible anyway. Right?
(i.e. this will change *sometime*, right? Please? :)
Cheers,
- Gulli
> -----Original Message-----
> From: David Megginson [mailto:[EMAIL PROTECTED]]
> Sent: 27. november 2001 16:20
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Sax-devel] Re: SAX and namespace attributes
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
