xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: DOM 3
Date Sun, 20 Feb 2005 17:23:45 GMT
Hi Cameron,

    Sorry to be slow about responding, but I've been trying to
come up with good answers and to be honest I don't really
feel like I have them right now, but here are my thoughts for now.

Cameron McCormack wrote:

> I've implemented DOM 3 Core and Events support for Batik, along with
> a number of tests for the new code.  

   This is great news.

> Before checking it in, though,
> there are still a couple of issues I want to nut out:

   There is one other issue which is that I would like to put
out a 1.5.2 before making such a large change (especially if it
is going to make things difficult for users on JDK 1.5 or less).
One option would be to fork the code base which would allow this
work to go in now and still allow for 1.5.2 (and more if needed).
At the very least we should lay down a CVS tag before this work
is checked in.

> 1. How should the lack of DOM 3 interfaces in JDK < 1.5 be handled?
>    For testing, I have updated the xml-apis.jar file with the DOM 3
>    class files and then used the -Xbootclasspath/p switch to make it
>    available before the DOM 2 interfaces.  This will then mean that to
>    get anything to compile or run, users will have to fiddle with the
>    bootclasspath themselves or install a copy of the xml-apis.jar in the
>    approved extensions directory.  

    Unfortunately, I _really_ don't like this.  This will make it hard
for people to develop and use Batik unless they are using JDK 1.5 which
will be a big barrier for people.  Also I think this would bar people
from using Batik as an Applet (unless the recipient had JDK 1.5 applet
software installed).

    So what to do?  The best thing I could come up with is a
"shadow" copy of the DOM3 interfaces.  There would be two copies of
this one that extended DOM3 one that extended DOM2.  This would allow
us to subclass of the shadow copy.  The problem is that because the W3C
interfaces return Node instead of 'ShadowNode' we would have to downcast
(to our shadow interfaces) everytime we wanted to call a DOM3 method
(otherwise it wouldn't compile or run on JDKs < 1.5).

    There may also be issues with compiling on one and running on
the other (not sure about this, I think that we might be fine
on this point).

> Is this acceptable?  (I guess this is what the Xerces and Xalan 
> people have to do.)

    I think this is a little different as I suspect that most of the
people dealing with this are mostly interested in the DOM Level 3
stuff.  With Batik I think a lot of people are still just interested
in SVG support (eventually this will change and DOM3 will become
more important, probably as JDK 1.5+ becomes more mainstream).

> 2. I was thinking about what should happen when processing version < 1.2
>    documents.  Since DOM 3 is pretty much a superset of DOM 2, I think
>    there doesn't really need to be any switching in the DOM code as to
>    which SVG version is being used.  If the AbstractNode class implements
>    the DOM 2 Node interface, it shouldn't matter that it also happens to
>    implement the DOM 3 functions, since that doesn't invalidate its DOM
>    2-ness.  The only reason I can think of to restrict access to the DOM
>    3 functions in this situation is to help document authors avoid
>    relying on DOM 3 functions in version < 1.2 documents.

    I tend to agree.  This does raise the issue of if we do the above
we are only "1.2 compliant" if they use a DOM3 xml-apis.

To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

View raw message