You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by sa...@ca.ibm.com on 2002/06/28 05:25:09 UTC

Getting Version Number (was: Re: Xerces and static mutability)

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
sandygao@ca.ibm.com



                                                                                                              
                    Andy Clark                                                                                
                    <andyc@apache.       To:     xerces-j-dev@xml.apache.org                                  
                    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 * andyc@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org


Re: Getting Version Number (was: Re: Xerces and static mutability)

Posted by Andy Clark <an...@apache.org>.
sandygao@ca.ibm.com 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 * andyc@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org