You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Elena Litani <el...@ca.ibm.com> on 2003/03/24 20:09:50 UTC
Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Hi Neeraj,
Sorry I have not replied to your message before. I've seen your latest
commit in which you add to the Xerces DOM HTML implementation
non-standard methods that are parts of the HTML interfaces in the Sun
JDK.
One of the concerns I have regarding this change is that if a user
compiles Xerces under Sun JDK and then attempt to use
getContentDocument() method as method on the HTMLFrameElement interface,
Xerces implementation will throw a runtime exception. However, if the
same code is run on IBM JDK, the "NoSuchMethodError" linkage exception
will be thrown. My take on this is that such behavior is not desirable,
since it breaks one of the virtues of Java - "compile once, run
everywhere". The behavior can get even more complicated if user chooses
to overwrite Xerces implementation of HTMLFrameElementImpl, providing
different document class -- compiling and running under Sun JDK will
work, however running the same code under IBM JDK will fail.
I believe we need to discuss this change more. Thus, I suggest you pull
back the change (from the main Xerces branch) before the release.
Thank you,
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Neeraj,
Neeraj Bajaj wrote:
> My experience is that
> DOM HTML implementation is not actively supported :-) Since there wont
> be any problem for all those people who use ANT to compile Xerces and
> it would serve most of the people, I dont see any point taking this
> issue further. Thanks for looking into it.
Thank you for your response! Just on time before the release! :)
Looks like we are not going to make the release today.. but hopefully it
will be out tomorrow.
After this release we should discuss what do we do with DOM HTML
implementation in Xerces (see Curt Arnold message).
Thank you,
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Posted by Neeraj Bajaj <ne...@sun.com>.
Hi Elena,
>>My
>>understanding is that since it is an implementation level change it
>>doesn't make difference. Had these changes not been done , any
>>application which has used getContentDocument() is compiled against SUN
>>JDK and run against IBM JDK would still be getting "NoSuchMethodError".
>>
>>
>
>I am not sure I understand. Before your changes, applications could not
>have used getContentDocument() since this method did not exist in Xerces
>implementation nor in the xml-apis.jar. But even if an application would
>attempt to use getContentDocument() before your change, it would have
>failed to compile under both JDKs: under Sun since Xerces does not
>provide implementation of this method,
>
Application written using DOM HTML api should not face any compilation
problem. What I was talking about compiling Xerces against JDK. My idea
was to fix the problem for remaining few set of people and not to send
any other message that Xerces supports this particular function ( or
might be supported in future ) My experience is that DOM HTML
implementation is not actively supported :-) Since there wont be any
problem for all those people who use ANT to compile Xerces and it would
serve most of the people, I dont see any point taking this issue
further. Thanks for looking into it.
Neeraj
Re: Xerces DOM HTML impl
Posted by Curt Arnold <ca...@houston.rr.com>.
I don't have any opinion on the issue that started this thread.
However, since the HTML DOM is rarely mentioned and had substantial
issues last time I looked, it seems like an opportunity to sound out a
path forward.
A decent time ago (maybe a year ago), I attempted to use the HTML DOM
implementation in the development effort of the W3C DOM test suite. I
ended up hacking a variant since the implementation at that time would
not read XHTML instead it would only read documents with uppercase tag
names and no namespace qualifier.
Given that and the number of other issues that I found, I suspect the
code is deadweight. It also looked pretty difficult to fix the
implementation without breaking any hypothetical application that used
it. Also, adding a parallel HTML DOM L2 implementation added a
surprising amount of bulk to the .jar file.
Some possible actions:
Do nothing (I suspect the most likely)
Change the current L1 implementation to read XHTML
Change the current L1 implementation to read XHTML and uppercased HTML
tag names
Remove the HTML DOM implementation
Remove the HTML DOM implementation and provide additional jars that
would support existing behavior, XHTML reading L1 DOM or XHTML reading
L2 DOM
Mark the existing implementation as deprecated and remove at a later
time
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Posted by Arnaud Le Hors <le...@us.ibm.com>.
I have to agree with Elena here. Poluting our code to allow one to ignore
our compilation framework and compile against a broken JDK doesn't sound
reasonable to me.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
> -----Original Message-----
> From: Elena Litani [mailto:elitani@ca.ibm.com]
> Sent: Tuesday, March 25, 2003 8:00 AM
> To: xerces-j-dev@xml.apache.org
> Subject: Re: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure -
> xml-xerces]
>
>
> Hi Neeraj,
>
> Thank you for the reply.
>
> Neeraj Bajaj wrote:
> > My
> > understanding is that since it is an implementation level change it
> > doesn't make difference. Had these changes not been done , any
> > application which has used getContentDocument() is compiled against SUN
> > JDK and run against IBM JDK would still be getting "NoSuchMethodError".
>
> I am not sure I understand. Before your changes, applications could not
> have used getContentDocument() since this method did not exist in Xerces
> implementation nor in the xml-apis.jar. But even if an application would
> attempt to use getContentDocument() before your change, it would have
> failed to compile under both JDKs: under Sun since Xerces does not
> provide implementation of this method, and under IBM one since this
> method is not defined on the interface. Given that any application code
> written AND compiled under either JDK would run the same.
>
> By adding this method, first, we *pretend* as we implement this method
> which we don't and I think this might give people false hopes that we
> might implement this method in the future.
> Second, an application that uses HTMLFrameElement.getContentDocument()
> now can compile under Sun JDK, but compiling such code using Ant or IBM
> JDK will fail.
>
> Talking about compiling directly, I would be very surprised to find
> people who actually don't use Ant. To build Xerces we do all kind of
> tricks in the build.xml file (excluding some files, for example) so how
> would someone achieve the same by compiling directly..? Thus, in my
> opinion, people compile Xerces only using Ant and thus there is no
> reason to add these method and potentially make applications depend on
> the level of JDK it was compiled and run against.
>
> I hope I've convinced you that we don't need this change :). If not, I
> don't think we have time to reach consensus before the release. So I
> would suggest again to remove this change and continue the discussion
> after the release (potentially changing the code in the next Xerces
> release).
>
> Anyone else has an opinion on this issue?
>
>
> > I think the concern you are raising is there because of a different
> > reason. It seems there is difference in DOM HTML apis part of two JDKs.
>
> Just to point out that the xml-apis.jar contains are the official DOM
> Level 1 HTML interfaces plus an extra DOM L2 interface
> DOMHTMLImplementation. On the other hand, the DOM HTML interfaces
> shipped in Sun JDK are hybrid between DOM L1 and DOM L2 HTML and could
> not be mapped to any official DOM version.
>
>
> Thank you,
> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Neeraj,
Thank you for the reply.
Neeraj Bajaj wrote:
> My
> understanding is that since it is an implementation level change it
> doesn't make difference. Had these changes not been done , any
> application which has used getContentDocument() is compiled against SUN
> JDK and run against IBM JDK would still be getting "NoSuchMethodError".
I am not sure I understand. Before your changes, applications could not
have used getContentDocument() since this method did not exist in Xerces
implementation nor in the xml-apis.jar. But even if an application would
attempt to use getContentDocument() before your change, it would have
failed to compile under both JDKs: under Sun since Xerces does not
provide implementation of this method, and under IBM one since this
method is not defined on the interface. Given that any application code
written AND compiled under either JDK would run the same.
By adding this method, first, we *pretend* as we implement this method
which we don't and I think this might give people false hopes that we
might implement this method in the future.
Second, an application that uses HTMLFrameElement.getContentDocument()
now can compile under Sun JDK, but compiling such code using Ant or IBM
JDK will fail.
Talking about compiling directly, I would be very surprised to find
people who actually don't use Ant. To build Xerces we do all kind of
tricks in the build.xml file (excluding some files, for example) so how
would someone achieve the same by compiling directly..? Thus, in my
opinion, people compile Xerces only using Ant and thus there is no
reason to add these method and potentially make applications depend on
the level of JDK it was compiled and run against.
I hope I've convinced you that we don't need this change :). If not, I
don't think we have time to reach consensus before the release. So I
would suggest again to remove this change and continue the discussion
after the release (potentially changing the code in the next Xerces
release).
Anyone else has an opinion on this issue?
> I think the concern you are raising is there because of a different
> reason. It seems there is difference in DOM HTML apis part of two JDKs.
Just to point out that the xml-apis.jar contains are the official DOM
Level 1 HTML interfaces plus an extra DOM L2 interface
DOMHTMLImplementation. On the other hand, the DOM HTML interfaces
shipped in Sun JDK are hybrid between DOM L1 and DOM L2 HTML and could
not be mapped to any official DOM version.
Thank you,
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces DOM HTML impl [was: Re: [GUMP] Build Failure - xml-xerces]
Posted by Neeraj Bajaj <ne...@sun.com>.
Hi Elena,
>Sorry I have not replied to your message before. I've seen your latest
>commit in which you add to the Xerces DOM HTML implementation
>non-standard methods that are parts of the HTML interfaces in the Sun
>JDK.
>
>One of the concerns I have regarding this change is that if a user
>compiles Xerces under Sun JDK and then attempt to use
>getContentDocument() method as method on the HTMLFrameElement interface,
>Xerces implementation will throw a runtime exception. However, if the
>same code is run on IBM JDK, the "NoSuchMethodError" linkage exception
>will be thrown.
>
>My take on this is that such behavior is not desirable,
>since it breaks one of the virtues of Java - "compile once, run
>everywhere".
>
>
Thanks for your reply. Please help me understand the issue here. My
understanding is that since it is an implementation level change it
doesn't make difference. Had these changes not been done , any
application which has used getContentDocument() is compiled against SUN
JDK and run against IBM JDK would still be getting "NoSuchMethodError".
I think the concern you are raising is there because of a different
reason. It seems there is difference in DOM HTML apis part of two JDKs.
It is not possible to achieve "compile once , run anywhere" in the
context when the APIs are different. So my understanding is that this
implementation level change has not changed the scenario. Moreover it
would not pose any compilation problem on any JDK.
>I believe we need to discuss this change more. Thus, I suggest you pull
>back the change (from the main Xerces branch) before the release.
>
>
My thinking is that scenario has not changed as a result of this
implementation level change. However, If you feel it need some more
discussion, I am totally fine with it and would be willing to do
necessary changes based on the decision taken. I would appreciate if we
see some consenus on it before the next Xerces (2.4) release is out.
However, If you feel that there are not any issues now i think we can go
out with Xerces ( 2.4 ) release.
thanks,
Neeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org