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 mail. > 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 drawback. 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 = problems.... 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 version. > 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 :) Cheers, Stephane --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
