[EMAIL PROTECTED] wrote: > Assume we do the same as Xalan did,: add a Version class to Xerces > 2.0.3/2.1 and later versions. Now assume the user has 2 versions of Xerces > in the classpath: Xerces 2.0.2 ahead of Xerces 2.0.3/2.1. If the user > instantiates a parser, it should be from 2.0.2; but if the user checks for > the Version class, he/she would get 2.0.3/2.1 (because 2.0.2 doesn't have > this class), which isn't correct. So I think this approach works in some > (maybe most) scenarios, but not always.
Hence my reference to "backwards compatibility". These are the very real situations that the users will face if we just remove the Version class altogether. I like the way that Xalan does it but perhaps we should keep both and deprecate the old one. > Adding a "getVersion" method to XMLParser won't have the same problem: if > such method is found on the parser, then it can be used to determine the > version number; if such method is not found, it'd be a 2.0.2 or earlier > version. I don't like this approach because it's tied to the XMLParser base class. Any versioning mechanism should be independent from implementation details in that version of the parser. Having a separate Version class does this; adding a method to XMLParser does not. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
