[EMAIL PROTECTED] wrote: > > Perhaps the difference is that we're a little closer to the API bleeding > edge. It's nice to think that when, as a community, we decide that DOM > level 3 is ready for prime time, we can simply include it in our API jar > rather than convincing another project--which has a whole host of other > consumers--that that's a good idea. For instance, if I'm not mistaken > crimson uses xml-commons code; if it were decided to move to DOM level 3 it > would instantly become broken since it wouldn't implement all the methods > in the updated interfaces.
Yes, crimson currently requires an xml-commons tree, but it does a checkout of a specific version of that tree so the code it obtains is stable. My opinion now is that it should work the way Xerces does now, which is to include a copy of a snapshot of xml-commons code. This makes is easier to build Xerces and does not require tagging xml-commons. I just haven't gotten around to fixing the crimson build yet. An optimization that could make this easier to maintain would be a build.xml target to copy and checkin code from xml-commons into xml-xerces. This scheme makes building xerces straightforward, but yet allows common API code to be integrated in a controlled manner. > > This is a tough problem though; xml-commons too will have to figure out a n > evolution strategy at some point. Yup, definitely involves more inter-project coordination. There may be different versions of xml-apis.jar and xalan version X must state that is works w/ xerces version Y, etc. -Edwin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
