Andy Clark wrote: > 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).
hi, namespace context seems like optional data - i think that in configurations that do not implement namespaces but just XML 1.0 it would be null right? > > 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. that would be very helpful to give precise error messages (requires Xerces 2.2.0 with support for namespace context in startDocument()). > > 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. that sounds like good survival strategy - i will certainly try to do this to try support Xerces 2.2.x and pre 2.2.x versions :-) > > 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. i strongly believe in backward compatibility as (it helps to grow usable programs and APIs) and breaking it only when it is absolutely required. thanks, alek --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
