Mailing-List: contact batik-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xml.apache.org
Received-SPF: pass (hermes.apache.org: domain of Thomas.DeWeese@kodak.com
 designates 192.232.121.200 as permitted sender)
Message-ID: <42193D9C.7060903@Kodak.com>
Date: Sun, 20 Feb 2005 20:47:08 -0500
From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Organization: Eastman Kodak Company
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: batik-dev@xml.apache.org
Subject: Re: DOM 3
References: <20050219003245.GA12529@port.mcc.id.au>
 <4218C7A1.9010009@Kodak.com> <20050221001829.GA22163@port.mcc.id.au>
In-Reply-To: <20050221001829.GA22163@port.mcc.id.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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