xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <stephane.baill...@haht.com>
Subject RE: XML APIs in Xalan and Xerces
Date Thu, 18 Apr 2002 15:54:37 GMT
Hi Neil,

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

mmm..I checked the list for the last 2 months and could not find a dedicated
thread so I tossed my grenade. :)

> 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 

Use these interfaces to provide an implementation.

For example one day I came out with a NodeFilter interface until I noticed
that there was an optional one in the DOM package. So it would have been
more clever from me to actually implements this NodeFilter rather than
creating a new non-standard one. It is a standard so why not use it and make
it available. It was stupid from me to reinvent something that already
existed, was available but I did not make the necessary effort to go to the
w3c site, look at the specs and figure that 'oh, there are more interfaces
here, cool, I can get them' :)

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

You said it. So why not ship directly dom2.jar from w3c ?
Apparently you're +1 for that considering your comment and your previous

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

erh... You can do quite a good job with an interface as a marker, see
EventListener :)

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

When you start using them :)

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

Actually I think that this 'versioning' issue is also one of the major java
There's still nothing to manage versions.... manifest is a quick way to see
things from a human point of view, sealing cause major problems, classpath =

So how are we suppose to version in a standard way ? difficult to answer.
Some will put the version in the code...not cool for people actually
deploying webapp and that have to deal with tons of jar, others will be in
the manifest and some will have nothing so your only issue will actually be
to decompile the code to figure out what's the version or to look at the

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

In this case, I'm absolutely truely sorry for having tossed the grenade, it
is now time for me to run away and hide...i'm leaving for vacation tomorrow,
I hope you will not suffer too much :)



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