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

Jake, thanks on the note on Xerces 2's DOM3 API. However, looking at 
this prompt me to ask this question. Why do we want to move XMLC to 
Xerces 2 and does moving to Xerces 2 really helps solving the problem 
with

However, the DOM Level 3 API used by is actually located at the 
org.w3c.dom. Moving that to depend on the Xerces 2's experimental 
packages will still causes the same problem we are having right now, 
not as frequently but still a possibility.

Let me try to state the problems we are encountering with the current 
XMLC and the reason why there are so many call for upgrading to Xerces 
2.

1. The patched Xerces in XMLC conflicts with the Xerces bundled in the 
system you are trying to integrate XMLC into. Example of this: Ant. 
Typically, you see the following exception when you run XMLC with Ant 
without deleting its default Xerces implementation.

Caused by: java.lang.NoSuchFieldError: fEntityHandler
   at 
org.apache.xerces.readers.XCatalog$Parser.setBase(XCatalog.java:472)
   at 
org.apache.xerces.readers.XCatalog$Parser.<init>(XCatalog.java:450)
   at org.apache.xerces.readers.XCatalog.loadCatalog(XCatalog.java:223)

2. The patched Xerces in XMLC conflicts with the W3C DOM API bundled in 
the system you are trying to integrate XMLC into. Example of this, 
Tomcat. You see something like certain methods not found on only of the 
org.w3c.dom interface. This is cause by the use of Level 3 API in XMLC.

Any other reason that call for upgrading XMLC to Xerces 2?

I am going to argue here that implementing XMLC using the unstable API 
in Xerces 2 such as org.apache.xerces.dom3  will eventually causes the 
same problem when we are finally done with moving XMLC to Xerces 2. We 
should have no problem with with second one. Since more and more system 
bundling Xerces 2 instead of 1, we are going to see the first problem 
more frequently if the Xerces 2 bundled has different version then the 
one we develop XMLC with in the case of experimental API change.

XMLC probably uses more of the DOM API then anything applications out 
there, thus it depending heavily on the DOM API, thus, sensitive to the 
API changes.

I am going to argue here is that without complete spec out why we want 
to move XMLC to Xerces 2 and evaluate a stable base to build XMLC, 
moving to Xerces 2 for the sake of moving to Xerces 2 will bring XMLC 
right back to where we are today. Still posting work around on this 
mailing list on how to get XMLC to work with your favorite system X. In 
this case, we will be posting delete the Xerces and use Xerces 2.x.

I think before we even attempt to move XMLC to Xerces 2, we need to 
figure the requirement for such request. Otherwise, just like I said, 
we will back to where we are right now.

I think first requirement for redesign of XMLC is Depending strictly on 
DOM Level 2.

David


On Tuesday, Jan 21, 2003, at 04:54 Asia/Shanghai, Jacob Kjome wrote:

> Hello Jacob,
>
> Sorry, I got a bit confused as I wrote the last message.
>
> org.apache.xerces.dom3 package does exist and org.w3c.dom3 won't ever
> exist.  It will always be underneath the org.w3c.dom package.  Sorry,
> I wasn't thinking.
>
> Anway, it is implemented, but since dom3 stuff like
> org.w3c.dom.DOMImplementationSource don't yet exist in Xerces2, it
> does look like they don't yet officially support it.
>
> Again, sorry for confusing the issue.
>
> Jake

-----------------------------------------------------------------
< ¨C¤Ñ³£ Yahoo!©_¼¯ >  www.yahoo.com.tw