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

> I have one other question, though.
>
> Will it matter that in certain cases, a document will have a different implementation than that of XMLC's DOMImpl classes?  For instance, lets say Xerces2 is in CATALINA_HOME/common/endorsed and XMLC is in WEB-INF/lib.  If I bootstrap the DOM by doing...
>
> DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
> DocumentBuilder dbuilder = dbfactory.newDocumentBuilder();
> DOMImplementation dImpl = dbuilder.getDOMImplementation();
> Document doc = dImpl.createDocument(null, "MyRootElement", null);
>
> Or, alternatively, by using DOM3
>
> DOMImplementation domImpl =
> DOMImplementationRegistry.getDOMImplementation("XML 1.0");
>
> Document doc = dImpl.createDocument(null, "MyRootElement", null);

This would depends on which DocumentBuilderFactory gets loaded by the classloader. If the one with xmlc is loaded, the default DOM implementation will be the system property for 'javax.xml.parsers.DocumentBuilderFactory.' Very likely, it's going to be the default DOM implementation in the system. In your case, likely to be DOM of Xerces 2. 

> Won't there be a clash of implementations?  Won't the DOM implementation in this case be Xerces2?  Does is matter?  I guess I'm probably sounding a bit naieve here.  I'm just not sure how it all these interactions affect each other?

It's a very good question. We really have to test this out.

> BTW, I was totally mistaken in thinking that Xerces2 doesn't support DOM3.  I was thinking that the org.w3c.dom.ls (Load and Save) package (which I've used already) was DOM2.  It is, in fact, DOM3.  The one thing I knew wasn't implemented yet was DOMImplementationRegistry.  That is the key to everything since it allows you to bootstrap the DOM without requiring JAXP or any implementation specific references and since Xerces2 didn't have that, I assumed that it didn't support DOM3.  How wrong I was.

Accessing DOM 3 functionalities from applications will be another issues all together. The DOM Level 3 API in Xerces 1 is different from DOM Level 3 API in Xerces 2. Xerces 1 is based on a earlier version of the draft. 

> Do we lose this functionality if we wrap the existing Xerces1 implementation up in XMLC?  We do, at least in the XMLC internals.  If XMLC application developers started using DOM3 and various other newer standard interfaces which have an implementation which is not the xerces version internal to XMLC and manipulate documents obtained by XMLC, do we run into any collisions?  

Nope. We will not losing any DOM Level 3 functionalities supported by the current Xerces 1 implementation. 

However, it's not really a good idea using DOM Level 3 at this point. It's still at the draft level and I'd rather wait until it's more stable. We are basically now struggling with using early draft of DOM Level 3 unintentionally.

> Doesn't the call to hasFeature() get pretty messed up since the Document, if created by Xerces2, does have the feature, but then XMLC can't deal with that feature because it is older, and vice-versa, make things extremely confusing?  How is this all handled in a clean way....or is this not an issue, somehow?

For now, it's hard to mix the DOM from Xerces 1 and Xerces 2. I would guess it's ok to interfacing them through standard W3C API. However, the actually implementation can vary and we may have a surprise. For example, trying to import into a Xerces 1 DOM with a node from Xerces 2. Again, this effect should be tested.

> Hmmm....  Unless I get good answers on this, I'm still leaning toward wanting a Xerces2 implementation of XMLC.  However, If the above turn out not to be issues, then I guess I'm right back with you in your suggestion to internalize the DOM and Parser implementations.

I think we would eventually go for Xerces 2 to replace Xerces 1 in XMLC. However, unless the standard DOM/SAX/JAXP API are enough to gather information for XMLC to correctly perform its job, we will still be depending on implementation of Xerces 2 and will still have to move the particular Xerces 2 into the XMLC private name space to keep it from clashing with an incompatible version of Xerces 2 existing in the environment.

David Li