You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Edwin Goei <ed...@sun.com> on 2001/08/15 01:18:29 UTC

xml-commons XML API and API evolution

I'm posting this to "general@xml" because it impacts serveral projects.

A while ago there were discussions about creating a xml-commons module
where common code for various projects would live.  For example, the
JAXP API (which includes parts of DOM Level 2 and SAX2) currently lives
there.  Also, there is a build.xml file that builds the code and creates
a file called xml-apis.jar.  (BTW, I would have preferred the shorter
"xml-api".)  

Here is a summary of how the current XML projects handle common code
which is currently duplicated in their respective modules:

+ xerces-j 1.x and xerces2-j
  + xerces.jar contains:
    + javax.xml.parsers
    + DOM L2: org.w3c.dom.*
    + SAX 2.0 core and ext: org.xml.sax.*

+ xalan-j 2.x
  + xalan.jar:
    + javax.xml.transform
    + DOM L2
    + SAX 2.0 core and ext
  + xerces.jar: same as xerces 1.x above

+ crimson
  + jaxp.jar:
    + javax.xml.parsers and javax.xml.transform
  + crimson.jar:
    + DOM L2 core
    + SAX 2.0 core and ext

In addition, there is the issue of multiple versions which I will not
focus on here.  For example, there may be early implementations of DOM
Level 3.  This means that we will need to have a separate copy of DOM L3
classes (in xml-commons).

I see these two competing requirements:
  1) Ease of use which implies fewer jar files
  2) Minimize code duplication which implies more jar files

Here are some possible outcomes:

  + Optimize for #1
    + e.g. classpath = xerces.jar xalan.jar (current packaging)
      where DOM L2 and SAX 2.0 is duplicated in both jars

  + Optimize for #2
    + cp = dom2.jar sax2.jar jaxp.jar xerces.jar xalan.jar
    + cp = dom3.jar sax2.jar jaxp.jar xerces.jar xalan.jar
      where only dom2 contains DOM L2, jaxp.jar contains javax.xml.*,
      etc.

  + 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

So my current thoughts are that we should maintain a common source
repository of code in xml-commons but optimize for ease of use (#1). 
This means that each project would obtain their _source_ copies of JAXP,
DOM, and SAX from xml-commons and then produce a single jar file like
xalan.jar and xerces.jar.  This means that xml-apis.jar would go away
and that code may be duplicated, but that distributions would be easier
to use.  What do you all think?

BTW, is it necessary that xalan.jar contains DOM and SAX classes?  Since
xalan depends on a parser in a separate jar, then maybe it can depend on
the parser for supplying the DOM and SAX classes and simultaneously
minimize duplication of code.  Even more reason to optimize for #1, yet
share common source code.

-Edwin

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