xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Kesselman" <kesh...@us.ibm.com>
Subject xml-commons XML API and API evolution
Date Fri, 17 Aug 2001 23:26:22 GMT
Took a quick look at this thead...

What we must not do, as far as I'm concerned, is put ourselves in a
position where the user sees _only_ the Working Draft version of the DOM.
Remember, the DOM is an API; we have to expect that some users _WILL_ have
their own implementations in addition to the ones we supply, and we really
should not ask them to track experimental -- and changing -- extensions to
that API.


For Java, putting the DOM into a separate JARfile may be a bit less
convenient it accomplishes that goal cleanly.

An alternative would be to build DOM2 into the higher-level JARfiles, and
make the folks who are actively experimenting with DOM3 expicitly reference
it before DOM2 on their classpaths. This is a definite nuisance for them...
but frankly, having the folks on the "bleeding edge" be the ones who have
to do more work sounds entirely reasonable to me.  (One could also do this
the other way around, but that agan put the burden on the wrong community.)

The only other good solution I can think of is to admit that the
experimental DOM is not "the" DOM, as we did during DOM Level 2
prototyping:  Create a new package (eg org.apache.xml.dom.experimental)
which contains a version of the Working Draft interfaces, modified to live
in that package and to subclass the "official" copy. Code which wishes to
either implement or exploit these new interfaces would import from this
package. Code which only needs access to DOM Level 2 would import
org.w3c.dom.*. The two would be fully compatable as long as only the DOM L2
interfaces were actively used. When DOM L3 becomes a Recommendation, we
would pick up the official DOM L3 APIs and deprecate/remove our
experimental package. Code would cut over simply by doing a global replace
of org.apache.xml.dom.experimental with org.w3c.dom... and in fact most
Java files would just change one Import statement. That's fairly low impact
on both communities, with a one-time cost to reconverge.


Of these, I think I like the separate JARfile solutions better than the
experimental package approach, with the "default" being the most recent
recommendation (DOM2) if one absolutely must be built into the "tool" JARs
for convenience.



I'm not sure what the implications are for C++ or other languages. But I
think the same principles should hold: if it is at all possible to compile
with one level of the DOM and run with another, we should not insist that
they commit to a level which is not yet Recommended.

______________________________________
Joe Kesselman  / IBM Research


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