1) I agree that DOM clients should use the generic org.w3c.dom interfaces. In this way the client code is portable. No need to move the generic DOM just for clients who *use* it.
2) Any additional xerces DOM functionality which we want to expose to clients, and support as value-add/convenience should be declared in additional *interfaces*. Clients coding against our DOM implementation is not a good idea. These additional interfaces should be in the same package as the DOM which supports them. 3) The Xerces DOM in org.apache.xerces.dom is a layered DOM with a simple DOM underneath and a Deferred DOM as subclasses of the simple DOM. These 2 could be broken out into 2 packages. Do we want clients to create DOM subclasses of the simple DOM?. This would be the real reason to move the generic DOM implementation into another package, but not a motivation to move it up above xerces. 4) Another motivation to break it out into multiple packages, is to allow multiple DOM implementations. Some may be subclasses of the simple DOM, others may be total rewrites. Combining the thoughts above, I suggest something like: org.apache.xerces.dom -- the generic DOM impl, and any interfaces we want to support as value-add. org.apache.xerces.dom.deferred -- deferred implementation org.apache.xerces.dom.xxx -- another implementation Again, due to statement#1, there is no real reason to move the generic DOM above the xerces package, but there are motivations to separate it into its own package. -Ralf
