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 Tue, 21 Aug 2001 23:38:19 GMT
Scott_Boag@lotus.com wrote:
> 
> > What do you mean by option #3?  Is this the compromise of a separate jar
> > file for the APIs?
> 
> Yes, -->
> 
> >   + Compromise, seems to be maybe what xml-apis.jar was for
> >    + cp = xml-apis.jar xerces.jar xalan.jar
> >      where only xml-apis.jar contains javax.xml, DOM, SAX
> 
> I don't love it, but it seems to me that these APIs are indeed general, and
> might ought to have their own jar file.

So how would you handle API evolution?  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.  The
Xalan build would need to build the DOM L2 version of xml-apis.jar and
the Xerces build would build the DOM L3 version.  Xalan may have
implementations of DOM interfaces that only support DOM L2 and not newer
methods added in L3, for example.  So it seems to me that you would need
to have separate versions of xml-apis.jar but they would have the same
name which would be really confusing.

Another issue which I have not brought up yet has to do with JAXP and
obtaining the platform default implementation, when running in an applet
in Netscape.  This is currently implemented by loading a resource file
from a ClassLoader.  This works fine for most applications, however,
when running as an applet in Netscape, it fails.  The reason is that the
code that loads the resource is contained in a different jar file from
the file that contains the resource itself.  Netscape considers this a
security violation and you must sign the applet and use a special API to
get around it, which many people are not willing to do.  (I can give a
more detailed explaination if you ask.)

There is also the ease-of-use issue.  So for these three reasons, I am
currently leaning towards sharing source code in xml-commons but during
the build process, copying the source to the individual project, such as
Xerces (or Crimson).  Once the source is copied, it can be built,
javadoc-ed, included in the source, and added to the single project jar
file.

> 
> On the other hand, "+ Optimize for #1" is probably a better short term
> solution, in that they will cause less user turmoil.

I am proposing this as a long term solution, not just a short term
solution.  The only difference with what is being done now in Xerces and
Xalan is that currently, the source code is _duplicated_ in each project
and not copied from xml-commons.  The change I am proposing would be to
remove the duplicated source and instead copy the code from xml-commons.

Comments?  BTW, the reason why I bring this up is to find out if there
is something I've overlooked before changing the crimson distribution to
work this way.

---------------------------------------------------------------------
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


Mime
View raw message