xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Goei <edwi...@sun.com>
Subject Re: xml-commons XML API and API evolution
Date Wed, 22 Aug 2001 17:09:16 GMT
Joseph Kesselman wrote:
> >Suppose a version of Xalan
> >supported DOM L2 and a newer version of Xerces came out that supported
> >DOM L3 then there would need to be two versions of xml-apis.jar
> Or, as you noted, copying the source code in at build time... but that
> raises other issues; it means the order of Xalan/Xerces on the classpath
> affects whether user code sees dom2 or dom3, which is not exactly obvious
> at first glance.
> Or, since DOM3 isn't a Recommendation yet, the dom-experimental package.
> Or dom2.jar/dom3.jar; select the appropriate one.  Our whole problem is
> that the bundled higher-level JARs don't deal well with evolution of
> standard APIs; breaking those out as independent units has costs but does
> have definite benefits.

It seems that the issue of ordering jarfiles on the classpath is
unavoidable which ever scheme is used.  It's true that having dom2.jar
and dom3.jar does make it more obvious, but I see these disadvantages
with this scheme (call it #2):

  + Makes it difficult for the user since they need to set
  + Does not fix the applet problem that I mentioned in an earlier email

In Scheme #1, the single jar file approach, if xerces supported DOM L3
and xalan used DOM L2, then the instructions would tell the user to set
CLASSPATH=xerces.jar,xalan.jar.  If the user just wanted to use xerces,
then they would just set CP=xerces.jar.  There is less to explain.  It
also fixes the applet problem.

So I'm not yet convinced that either scheme #2 (avoid duplication) or #3
(a separate xml-apis.jar file) is the best way to go.


In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message