You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Cameron McCormack <ca...@aka.mcc.id.au> on 2005/02/19 01:32:46 UTC
DOM 3
Hi Thomas and others.
I've implemented DOM 3 Core and Events support for Batik, along with
a number of tests for the new code. Before checking it in, though,
there are still a couple of issues I want to nut out:
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. Is this acceptable? (I guess this is
what the Xerces and Xalan people have to do.)
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.
Thanks,
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> What are you compiling with? JDK 1.3? That doesn't have
> xml-apis at all (they were added in 1.4 as DOM 2). In which
> case my point about the xalan might still be valid.
No, with JDK 1.4. Anyway, don't worry about this any more. :-)
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> Yeah, the strange thing was that I didn't have to change the 'compile'
> target at all. Just having the DOM 3 interfaces in the classes
> directory allowed me to compile the main sources.
What are you compiling with? JDK 1.3? That doesn't have
xml-apis at all (they were added in 1.4 as DOM 2). In which
case my point about the xalan might still be valid.
>>One thing that occurs to me is that the test build
>>includes the 'libs-build-classpath' - which I think includes
>>xalan - which probably has xml-apis in it (although why they
>>would override your 'bootclasspath' stuff I don't know).
>
> If I take the extended DOM interfaces approach this should become a
> non-problem.
If it works as I think it will ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> I don't know for sure, if you tweaked the 'compile' target
> then you probably need to tweak the 'compiletest' target as well.
> Otherwise I would compare the two targets and see how they
> differ.
Yeah, the strange thing was that I didn't have to change the 'compile'
target at all. Just having the DOM 3 interfaces in the classes
directory allowed me to compile the main sources.
> One thing that occurs to me is that the test build
> includes the 'libs-build-classpath' - which I think includes
> xalan - which probably has xml-apis in it (although why they
> would override your 'bootclasspath' stuff I don't know).
If I take the extended DOM interfaces approach this should become a
non-problem.
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Camron,
Cameron McCormack wrote:
> And another thing: I am trying to put my test cases into regard, but I
> come up against the DOM 3 interfaces problem here, too. Compiling the
> main sources works fine but when compiling the test sources it finds
> only the DOM 2 interfaces, and so my tests don't compile.
>
> Any hints?
I don't know for sure, if you tweaked the 'compile' target
then you probably need to tweak the 'compiletest' target as well.
Otherwise I would compare the two targets and see how they
differ. One thing that occurs to me is that the test build
includes the 'libs-build-classpath' - which I think includes
xalan - which probably has xml-apis in it (although why they
would override your 'bootclasspath' stuff I don't know).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
And another thing: I am trying to put my test cases into regard, but I
come up against the DOM 3 interfaces problem here, too. Compiling the
main sources works fine but when compiling the test sources it finds
only the DOM 2 interfaces, and so my tests don't compile.
Any hints?
Thanks,
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> Now that I think of it, and that I've done the work of creating these
> extended DOM interfaces :), is there any need for them at all? If
> users of the Batik DOM classes have to downcast to get access to the DOM
> 3 methods, why not just make them cast to one of the dom.Abstract*
> classes?
Well once again it is the issue of new classes. With the shadow
the only thing that needs mods is the shadow classes, between,
DOM 2 & 3. Of course if the new classes "show through" and there really
is no change then perhaps they aren't needed (although the do have
the nice property of being an interface we can point to that could be
a little more public than our Abstract classes).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Now that I think of it, and that I've done the work of creating these
extended DOM interfaces :), is there any need for them at all? If
users of the Batik DOM classes have to downcast to get access to the DOM
3 methods, why not just make them cast to one of the dom.Abstract*
classes?
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> Thomas DeWeese:
>
>> 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.
>
> Ok. How about I make a branch for this significant change stuff.
> Should I put any new SVG 1.2 code (things that require more than just
> adding a new dom.svg12 and bridge.svg12 class) in there too?
Yes, I would think so (doesn't a lot of that stuff need/want
some of the DOM 3 stuff).
> I'm nearly finished the sXBL code, so that could go in there
> as well.
Also very cool. You have been busy.
>> 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.
>
> Would you really need the one that extended the DOM 3 interfaces? If
> you just extend whatever DOM interface is available, to add the DOM 3
> methods, it shouldn't matter that under JDK 1.5 the DOM 3 methods appear
> again on the extended interfaces.
This is mostly true, except that I presume DOM 3 adds some new
classes and for things to work right they need to subclass the DOM3
class in the DOM 3 shadow, and nothing in the DOM 2 shadow. I
suppose if we really wanted to we might be able to include those
interfaces (well really all of DOM 3 xml-apis, but only the new
classes would "show through" because the others would be hidden by
the JDK classes - I don't know for sure if that would work but I
think it would...).
>>>[...DOM 3 methods in version "1.1" 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.
>
> Yeah, it won't be strictly DOM 3 compliant when compiling on JDK < 1.5.
> It seems a reasonable tradeoff for not having to messing with
> bootclasspaths.
We will need a FAQ but I agree that it is probably the best
that can be accomplished.
> Also, I was writing the other night support for the mouse wheel event of
> SVG 1.2, but the AWT MouseWheelEvent is only supported in JDK >= 1.4.
> What do you think the strategy for including this should be? Break out
> the MouseWheelEvent specific code into a helper class and compile this
> in conditionally with some trickery in Ant?
FOP has a code structure of src/java, src/java-1.4, so they
can multiple versions of the same class for different JDK builds.
For a case like this it would probably be best to move most of
the code up into a baseclass and then try and have only one
or two methods that are split across JDK versions (like
addGVTListener, in the 1.3 version it would just create
the baseclass Listener, in the 1.4 it would create a subclass
of the baseclass Listener which also handled mouse wheel events -
this is just off the top of my head as an example I haven't looked
at the code enough to know if this is a complete solution).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> 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.
Ok. How about I make a branch for this significant change stuff.
Should I put any new SVG 1.2 code (things that require more than just
adding a new dom.svg12 and bridge.svg12 class) in there too? I'm nearly
finished the sXBL code, so that could go in there as well.
> Unfortunately, I _really_ don't like this.
It is ugly! I wonder whether W3C shouldn't have extended their
org.w3c.dom interfaces rather than replacing them.
> 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).
Oh, yes, that applet reason is a good one.
> 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).
Would you really need the one that extended the DOM 3 interfaces? If
you just extend whatever DOM interface is available, to add the DOM 3
methods, it shouldn't matter that under JDK 1.5 the DOM 3 methods appear
again on the extended interfaces.
> > [...DOM 3 methods in version "1.1" 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.
Yeah, it won't be strictly DOM 3 compliant when compiling on JDK < 1.5.
It seems a reasonable tradeoff for not having to messing with
bootclasspaths.
Also, I was writing the other night support for the mouse wheel event of
SVG 1.2, but the AWT MouseWheelEvent is only supported in JDK >= 1.4.
What do you think the strategy for including this should be? Break out
the MouseWheelEvent specific code into a helper class and compile this
in conditionally with some trickery in Ant? Or, have two different
versions of (for example) BridgeEventSupport (one extending from the
other) and then choosing which one to include in Ant. Though this
second one wouldn't work with BridgeEventSupport, being a class full of
static methods.
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: DOM 3
Posted by Thomas DeWeese <Th...@Kodak.com>.
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