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

I regard to wrapping XMLC's version of Xerces1 into our own
namespace.....

I'm not clear on how this would work?  Does this mean that people
using XMLC would no longer access, say.... org.w3c.dom.Document and the
like?  Because that is the issue at hand.  In order to think
about putting XMLC in a webapp's WEB-INF/lib directory, it can't have any
endorsed packages.  org.w3c.dom is an endorsed package and the JDK
or jars added to endorsed directories will override any we add to
XMLC.  The same goes for org.xml.sax and javax.xml.*.  If we do
that and we want to keep XMLC totally independent of any outside parser
containing those packages, then we necessarily force coders to do
something like access org.enhydra.xmlc.dom.Document rather than
org.w3c.dom.Document.  I don't think this is a good idea at
all!  What XMLC does internally shouldn't affect peoples' use of the
standard API's for DOM and XML programming.  This would actually
hinder Barracuda since, in theory, it should work generically with any
DOM templating engine, not just XMLC even though the focus has been 100%
on XMLC thus far.

As I see it, we either need to move on to support the latest Xerces2 or
go with something like DOM4J.  The DOM4J thing will probably make it
harder to port existing apps to XMLC since many use the DOM directly in
addition to XMLC's api, but it would solve our problems in the long run
since DOM4J doesn't use endorsed API's except in providing objects that
transform DOM and XML standard API objects to DOM4J objects and
vice-versa.  Sticking with standard DOM stuff is the way to go if we
want to keep compatibility with existing XMLC apps, but now we have to
choose an implementation (at least for LazyDOM).  The one that
everyone uses currently is Xerces2.  Maybe we can ask the Xerces
group what the plans for Xerces2 are.  Will it be dropped and
refactored for a newer and better Xerces3 branch like Xerces1 was, or
does Xerces2 have some staying power?  My gut feeling is that the
latter is true.

The other issue we have in wrapping Xerces1 into our own namespace is
that we will then never have any motivation to move it out.  We lose
accessibility to performance increases that a package like Xerces2 might
provide over Xerces1.  We may also have difficulty working
with  new API's such as Jaxen which deal with standard API's +
DOM4J, JDOM, and a couple others.  It seems like wrapping everything
into our own namespace causes more problems than it solves.

Please point out the errors in my logic.  Otherwise, the issues I
have raised need to be addressed before we move on wrapping all this
stuff into our own namespace.  Maybe I just don't understand how it
would work.  If so, please explain.


Jake

At 12:43 PM 1/23/2003 +0000, you wrote:
> This is a very good point. We don't
> actually need Xerces2, we just need XMLC
> to work with everything else. And with the automated refactoring
> tools
> available, this should be an easy win.
>
> +1 for David's solution.
>
> Adam.
>
>
> ----- Original Message -----
> From: "David Li" <david@xxxxxxxxxxxxxxxxx>
> To: <xmlc@xxxxxxxxxxx>
> Sent: Thursday, January 23, 2003 11:08 AM
> Subject: Re: Xmlc: 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
> >
> > _______________________________________________
> > XMLC mailing list
> > XMLC@xxxxxxxxxxx
> >
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc