xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: xml-commons XML API and API evolution
Date Fri, 17 Aug 2001 12:12:37 GMT
(Oh, and PS: please *don't* post HTML mails to the list)


---- you  Edwin Goei <edwingo@sun.com> wrote ----
> 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".)

I know: the voting on the .jar name was a little disorganized, so I'm not
sure we got all the opinions.  But I kind of like xml-apis, since it does
have multiple API sets.  And it's only one little bitty character more -
still under the 8.3 if anyone cares about ancient DOS limitations...  8-)

> Here is a summary of how the current XML projects handle common code

Excellent!  Thanks for the summary.

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

Xalan builds have a checked in copy of the shipped xerces.jar from the most
recent xerces 1.x release, this is for developer convenience.

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

DOM level 3 is a separate issue, since it's not a finished standard yet.
We should be careful to follow all their reccommendations to not break
anyone who just wants DOM L2 while we're including new DOM L3 code (Xerces
had some mixed up DOM classes recently that caused minor Xalan headaches).
I'm sure Joe K. will chime in with some ideas.

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

We might even want to think about the ramifications for two common
communities: developers and users.

Users clearly would want fewer jar files at runtime, and wouldn't care
about code duplication or maintenance.  They just know they need to get XML
parsed or stylesheets run or website content managed, so they simply
download a distro as-is and expect it to work with a minimum of setup.

Developers need to both run our applications in their local workspaces and
maybe their company's servers, as well as be able to make changes and
easily recompile, along with being able to submit patches from their local
workspace.  I think an important factor here too will be thinking both
about experienced developers as well as newer ones.  Most people on this
list probably wouldn't mind having to checkout xml-commons to do most other
xml- work.  But new developers or 'occasional' code putterers might find
this confusing to have to go and get a completely separate product
(xml-commons) to do work on xalan or xerces or the like.

> + 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 (#3), 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

My first thought: have each project import only the specific *sources* they
need, and compile them into the .jar.  This way we only have one copy of
the sources, but no need for an extra xml-apis.jar; each project will
include the minimum compiled .classes that they need to run.  For this,
there are important working questions, like:
-- do the projects copy in the sources and leave them hanging around (and
thus leave them in the src dir of the distro) or do they simply refer to
them, or refer to a build target, in the local xml-commons repository?

Another big question is: how do we present this (i.e. document) for
multiple xml projects? We want to be sure that users and developers alike
can easily use and compile each project, even when they want to mix
projects or have both cocoon, xalan, and crimon on their disk at the same
time.  Each project needs to be careful to include the common code they do
need, but hopefully not include anything extra to avoid duplication.

Another issue: how do we deal with versioning?  I'm not as concerned yet
with DOM L3 (since I think they explicitly have ways to do this, like using
separately named rangex packages for new L3 classes until their finalized)
but more with Xalan/Xerces/Cocoon/etc versions, and JAXP versions.  I.e.
what if a user really wants to use the current Xalan with new JAXP stuff,
but with the old Xerces?

Hmmm.  Needs more thought, I'm just starting to ramble.  Thanks for
starting the conversation: I was just about to add an experimental option
to the xalan build.xml to pull in the xml-commons code!

- Shane


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