Hi Arno,
Your response was very informative!
Looks like the package switch from dom.html to dom.html2 came between the following releases...
http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/java-binding.html
and
http://www.w3.org/TR/2002/CR-DOM-Level-2-HTML-20020605/java-binding.html
So, where is the source being kept for xmlParserAPIs.jar and xml-apis.jar because it doesn't exist any longer in the Xerces2-j source. Are these just API's which are collected from external sources where the standards are stored....as of Xerces-2.4.0? And how is xml-apis.jar different from xmlParserAPIs.jar? Why have both?
A further question. Since Xerces2 seems to be doing the "correct" thing in distributing only the original html dom level1 standard interfaces rather than the level2, it seems that consumers of the interfaces ought to fall into line with the original standard, if possible. To that end, what is the appropriate change to make to the following code...
optionElement.setSelected(selectionModel.isSelectedIndex(i));
would it be?.....
if (selectionModel.isSelectedIndex(i)) optionElement.setAttribute("selected", "selected");
else optionElement.removeAttribute("selected");
Or is there another way?
I based this on the following implementation of setAttribute() in org.apache.html.dom.HTMLElementImpl.java
void setAttribute( String name, boolean value )
{
if ( value )
setAttribute( name, name );
else
removeAttribute( name );
}
BTW, the javadoc for that seems to be incorrect. It claims "If the value is true, the attribute is set to an empty string". That is, obviously, not the case. If the value is true, the attribute value is set to the value of the "name" parameter, which is the same as the attribute name. So, instead of <option selected ...>, as the javadoc seems to claim, it would be <option selected="selected" ...>. I'm actually not complaining about the behavior (I don't want that to change), I'm just saying that javadoc should be corrected to state what actually happens.
thanks,
Jake
At 01:37 PM 5/20/2003 +0200, Arno Schatz wrote:
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]
