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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
