Hi Jake,
The problem is that the HTML DOM Level 2 early Working drafts changed the API of some HTMLElements, but not the package names (see http://www.w3.org/TR/2000/WD-DOM-Level-2-HTML-20001113/java-binding.html). Before the final recommendation the package names where changed to org.w3c.dom.html2, thus ending the confusion about incompatibility.
The source of the problem is that people were using the interfaces from those early Level 2 interfaces and getting into compatibility issues. This poped up again on the Xerces-J developer list when Neeraj discovered incompatibilities with JDK1.4, because JDK1.4 ships with such an early Level 2 api (having the old package name, but some new methods). See thread 'Xerces DOM HTML impl' on the developer list.
Since, the HTML DOM implementation provided by Xerces is really DOM Level 1, they are shipping the 'real' DOM Level 1 API with Xerces. However, this may result in some tricky classpath issues if you are using JDK1.4, since the Xerces classes don't provide the additional methods found in JDK1.4 (HTML DOM Level 2) but not present in the original HTML DOM Level 1 API.
I also think the only clean solution is to use HTML DOM Level 1 API or provide a DOM Level 2 Implementation, but then use the final recommendation with the new package names. Then you won't have any incompatibilities any more. (But AFAIK, there is no Level 2 implementation out there :-( ).
Also another point to mention is that HTML DOM Level 2 is based on DOM Level 2 Core, while Level 1 is based on, you guessed it, Core DOM Level 1. So if you are using Xerces 2, you will use DOM Core Level 2 + HTML DOM Level 1. This seems to works ok. I just found some performance drawbacks, for example, HTMLDOcument implements the 'getElementById' method in a very slow fashion (searching the tree every time). This method is provided in class Document since Level 2 (and implemented by Xerces as Hashtable lookup).
hope that helps, Arno
Jacob Kjome wrote:
Hello,
I ran into a very strange issue when using the org.w3c.dom.html interfaces in the release versions of Xerces2 (tried 2.3.0 and 2.4.0). The binaries of the xmlParserAPIs.jar and xml-apis.jar both seem to contain a different version of the html dom interfaces than what comes in the source. For instance, in the Xerces-J-src.2.3.0.zip download, when I browse to org.w3c.dom.html.HTMLOptionElement.java, said file contains the method setSelected(boolean). However, when I grab the class file from the binary release (Xerces-J-bin.2.3.0.zip) it HTMLOptionElement does not contain that method. What gives here?
Another very confusing thing is the source download for the 2.4.0 distribution (Xerces-J-src.2.4.0.zip) contains only a single file in the org.w3c.dom.html package ( HTMLDOMImplementation.java ). Where are rest? Well, maybe in the xml-apis--src.zip that comes in the Xerces-J-tools.2.4.0.zip download. Is that right? Well, the problem here is that the w3c htm dom being used there is based on the original html dom 1 source released back in 1998. HTMLOptionElement did not have the setSelected(boolean), only getSelected(). But anyone who has used Xerces-1 has already been used to using newer dom interfaces with setSelected(boolean) in HTMLOptionElement.
Can anyone clear this up?
1. Why has Xerces2 reverted to an older version of the dom interfaces than Xerces1 had?
2. Why does the source download for Xerces 2.3.0 come with newer versions of the dom interfaces than is released in the 2.3.0 binaries (or any of the Xerces2 binaries, for that matter)? And why does the source download for Xerces 2.4.0 not have these newer sources anymore?
3. Where did these newer sources come from anyway? After the html DOM1 release, all work was done on the html DOM2 release,. but that falls under a different package named org.w3c.dom.html2.
Curiously enough, if I extract the org.w3c.dom.html package from the Xerces 2.3.0 source distribution, compile the interfaces, jar the interfaces, and put the jar in my build classpath, everything compiles just fine.
extremely confused,
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
