Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
Subject: RE: XML APIs in Xalan and Xerces
To: general@xml.apache.org
Message-ID: <OFDCA1A828.F445D869-ON85256B9E.007A5AFB@torolab.ibm.com>
From: neilg@ca.ibm.com
Date: Wed, 17 Apr 2002 18:17:18 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Stephane,

>(and thanks for taking the time to reply about these boring issues)

For a boring issue lots of folks seem to be interested!  :-)  This comes up
once every couple of weeks these days it seems.

>If you keep this jar, I would suggest adding a manifest the way xalan
folks
>do.

Good idea!  Provided I can crib the xml-commons code for doing this easily
enough, I'll try and get this in our next minor release.

>Same for me about DOM for example. I would rather see all interfaces in
one
>jar than part of it as some parts are optional but at least if you need to
>use XML heavily these interfaces exists, they are available, you can use

Sure the interfaces are there, but what possible good is that to you if you
don't have an implementation???  For instance, I see that xml-apis.jar now
contains the DOM views interface.  To use this, you've still got to fish
around for an implementation.  If that implementation doesn't happen to use
xml-commons--and let's face it, most software in the world is non-Apache
and most probably won't see the light of xml-commons--you're probably going
to have to put it, and its API's, before xml-apis anyway since you don't
have any way to tell absolutely whether it happens to be compatible with
whatever xml-apis contains.

To my mind an API is no good without an implementation, and a particular
version of an implementation is only guaranteed to work with a specific
version of an API.

The xml-commons idea is to have one API jar file that everybody implements
portions of; I don't think it's really been discussed as to how this
evolves over time.  When projects need to be back-leveled for some
reason--like J2EE/J2SE requirements for us--then this approach starts to
break down because it's not clear what the "correct", up-to-date thing to
do is.  Same holds if projects want to support new features:  at what point
should DOM level 3 interfaces appear in API's?

The other way to look at things is to have implementations make clear what
versions of APIs they support (sorry we're guilty of not doing this well
now...) and ship them.  applications can then make it clear what API
versions they require and you can find your API and implementation of the
correct version in one place--the same place you'd have to go to get your
impl anyway.  So long as implementations are careful to provide only those
APIs they actually implement, you should have no classpath problems and no
duplication (this assuming two impls you need don't implement the same API.
But if this is true you'll have classpath problems even with an xml-apis
style jarfile, since one impl has to come before the other.)

Anyway, let me get off my soapbox and run for cover--I can't believe no one
will jump on this post.  :-)

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com


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