Re: Moving XMLC to Xerces 2 won't help...

> > So, what happens is that if one needs to use an older API, you
> > force that API on everything running under that appserver since it has
> > to be loaded in a parent ClassLoader where all apps see it.  For apps
> > that require newer versions, this causes some bad collisions.
>
> Yes, this is generally an unsolved problem in java!

And the introduction of endorsed API makes it even worse. On top of 
that, the endorsed directory behavior isn't as documented.

> > Now, as far as DOM3 goes, how much DOM3 specific stuff is used in
> > XMLC?  I wonder how big of an issue that is?
>
> I don't  think any; guys???

Yes, Mark you are busted for using DOM Level 3 API. In the org.w3c.dom 
package in Xerces 1, many methods are DOM Level 3 and several of them 
are used. Richard has a patch using reflection to deal with the issues 
and there is a list of DOM Level 3 methods used.

> Another problem is that the LazyDOM is a derived DOM, which makes it
> implementation-dependent.

I think we should just move the patched Xerces into the 
org.enhydra.xmlc name space. From the point of LazyDOM, I'd argue that 
it makes perfect senses to do so. LazyDOM depends not on interfaces but 
implementations of the particular Xerces it uses. We can not really 
move LazyDOM among different versions of Xerces 1 and expect it to just 
work.

I think we should really separate out the issues to 3 part of Xerces:

1. Parser: DTD access
2. DOM: LazyDOM depending on it
3. W3C DOM API: DOM Level 3

We could attach the second one by moving the Xerces DOM used by LazyDOM 
into a different name space. In the old days, when XML parser is 
novelty, it nice to be able to use XMLC and get a XML parser as a side 
benefit. However, the problems we are having right now is really too 
many Xerces around and the conflicts amount them are the problem.

I think I found the shortest path to solve the problem of integrating 
XMLC into today's environment. Instead of trying to push XMLC to more 
standard base, we push the part of XMLC that's conflicts with the 
environment into XMLC's private name space. Instead of removing 
dependency on Xerces and move it toward JAXP based, we just push the 
Xerces XMLC depending on into XMLC's private space.

XMLC probably uses DOM more extensive then any applications out there. 
The common API such as JAXP are taking a lowest common denominator 
approach to the API.

Drawback of this? Adding 1 MB of xmlc-xerces.jar to the size of your 
web application. Would this really be a problem to anyone?

> > So, the question is, is it possible to stick to the more generic JAXP
> > and DOM2 API's (and our own internals) and still have a functional 
> > XMLC?
>
> No, although it might be possible to isolate it more; there were 
> certainly
> some short-cut taken.

As above, I don't think moving to JAXP is a solution.

> My feeling is that a short-term approach of getting things ported
> to the latest xerces and getting the bug-fixes submitted would at least
> keep people going with xmlc.

I think we really have to look at why we need to move to the latest 
Xerces. We need to step back and look at the reason why so many want 
XMLC to move to Xerces 2. The #1 reason is to not having to alter the 
environment to suit the usage of XMLC. Users want to be able to package 
up the XMLC in the war and deploy the app to the application server 
without worrying about the conflicts between XMLC and their 
environment. However, from the point of view of the developers, we need 
the features provided by the specific implementation of Xerces to make 
our life easier without having to work around the limitation of common 
API.

I think moving XMLC to latest Xerces isn't a solution. Integrate the 
Xerces XMLC depending on into XMLC's private space and have XMLC play 
nicely with the environment is.

David Li