Elena Litani wrote: > After the updates, I wonder if NamespaceContext should > be a class rather than an interface. Currently this > interface has a reset() method that is normally not a > part of an interface and it requires that strings are > internalized/or added to the SymbolTable. Internally we > always use util.NamespaceSupport implementation of this > interface and I don't see why would somebody want to > implement NamespaceContext in some other way...
It doesn't matter what the method is called, for a truly read-write interface, we need a way to remove all of the namespace bindings. Since there's no way to query the context depth, you can't pop the correct number of contexts off of the stack. Currently, nothing in the framework requires the use of a symbol table or internalizing strings. But if you make NamespaceContext a class, then you introduce implementation dependencies into the framework which I really don't like. > Given that XNI already has some classes (QName, > XMLString) adding one more should not be a problem. The difference is that QName and XMLString are merely structures. And the only "behavior" they have is a set of convenience methods for setting the values of the struct. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
