xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <cam-batik-...@aka.mcc.id.au>
Subject DOM 3
Date Sat, 19 Feb 2005 00:32:46 GMT
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.



  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

View raw message