Hi Jacob, David,
Jacob Kjome <hoju@xxxxxxxx> writes:
> I mostly agree with your sentiments. The biggest reason I would like
> XMLC to be compatible with Xerces2 is for compatibility with modern
> environment.
This seems to be the biggest problem; also the fact that a custom version
of xerces is needed makes it that much harder for an end user to sort
things out. Although I realize that I am nieve in thinking someone could
come in an sort out the bugs fixes, because the way to test a most of the
xerces issues is to run the xmlc tests. Sigh.
> 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!
> 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???
> There are other places where we
> use Xerces specific classes such as Xerces-specific DOM parsers and
> whatnot. In many cases, I think we can use more of the generic JAXP
> API instead.
The problem here is that the DOM2 and SAX/2 APIs (which is really all JAXP is)
doesn't provide the required DTD information. (I haven't really looked at
DOM3 and don't know where SAX is currently at).
Another problem is that the LazyDOM is a derived DOM, which makes it
implementation-dependent.
> 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.
> Alternatively, how much effort would it be to move to DOM4J.
Gut feel is it would be a large amount of work; requiring some
major rearchitecting.
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.
Mark
|
| 
