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

David Li <david@xxxxxxxxxxxxxxxxx> writes:
> >> 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.

Damn, can't pull anything over on you!!  Actually, I suspect it wasn't
intentional, just didn't realize I was doing it.
 
> 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.

This is a really interesting idea; it certainly solves a problem in a
pragmatic way.  It bugs me a lot, but it does solve the problem.  Guess better
the xmlc developers suffer than the users.

This doesn't eliminate the need to track xerces; as one would still want to
get xerces bug fixes and performace enhancements.  If it goes on too long,
it's a more painful to merge.  But it does isolated the user.  They still have
the same problem with other package, but at least they will not blame XMLC.
 
> 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.

Take a look at the SAX2 Extensions 1.0
         http://www.saxproject.org/?selected=ext
and
        org.xml.sax.ext.DeclHandler

I think this will give xmlc the information it needs to be independent of
a parse implementation.  Hmm, I wonder; yes!  Xerces 2 claims to implement
this interface.

This doesn't solve the problem with the DOM implementation; but better 
to fork just a DOM implementation instead of whole parser. This will
require more investigation, but it looks like it might do the trick.

Mark