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.
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.
Or we can do both?
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Andy Clark
<andyc@apache. To: [EMAIL PROTECTED]
org> cc:
Subject: Re: Xerces and static mutability
06/27/2002
10:49 PM
Please respond
to
xerces-j-dev
Joseph Kesselman wrote:
> At one point, some folks were trying to standardize an
> org.apache.<projectname>.Version class which every project would
> support, and which would contain both a main() (for easy querying from
> the command line) and a set of calls for retrieving components of the
> version programmatically. That's the approach Xalan has taken. Any
> chance we could persuade Xerces to adopt it?
I took a look at the Xalan Version class and I don't
see any reason why we couldn't do the same. The only
difference would be the presence of the "development"
version number since we don't have those kinds of
releases.
--
Andy Clark * [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]
