Aleksander Slominski wrote: > maybe instead of adding new parameter namespace context could be passed > as part of Augmentations (using some well defined key)?
I don't know if I like this answer to the problem. It would certainly work w/o changing the XNI interface but is again an implicit requirement placed on the users of the interface. I think that the Augmentations object should be used for out-of-band data, not for something fundamental to the document's infoset (e.g. the namespace context). > is there a good way to detect and deal with such changes when using > xerces XNI from outside xercesImpl.jar? We should definitely think about this. I have also wondered about versioning XNI so that when changes are made, people have a way of knowing. > making such backward incompatible change will not only break my code > but also introduce lot of possible bugs if people will try to use my code with older >version > of Xerces 2 (something like incompatible class change exception throw to the user > comes ot mind ...). I ran into the same problem with my NekoHTML parser and my other XNI-related tools when methods were changed a few months ago. It actually turned out that it wasn't a very big deal. In the end, I just added the new method and left the old method there. In this way, it works with both the old and new versions of the interface. And it shouldn't matter whether you compile it with the old or new OR even if you run it with the old or new one since the method list will be verified at load-time. > so iw ould liek to propose to keep start/enPrefixMapping() methods but deprecated > and use Augmentations in startDocument() to pass namespace contenxt for those > that needs it. This can also be handled but it's a little more work. Again, you should keep the older methods in place but then handle the case where the namespace context is passed to the new startDocument method. But I realize that this is all a pain because I've been through the same thing myself... and will have to go through it again once the change is made. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
