Re: Keeping SVG 1.2 code separate from SVG 1.1 code

Cameron McCormack wrote: Thomas DeWeese: One option we do have available is to have DOM 3 methods throw exceptions if we are processing a 1.1 document. This still isn't great since you really want to pick these things up at compile time (at least for Java - for JavaScript it doesn't matter

Re: Keeping SVG 1.2 code separate from SVG 1.1 code

Thomas DeWeese: > One option we do have available is to have DOM 3 methods > throw exceptions if we are processing a 1.1 document. This still > isn't great since you really want to pick these things up at compile > time (at least for Java - for JavaScript it doesn't matter much). > I suppose

Re: Keeping SVG 1.2 code separate from SVG 1.1 code

Hi Cameron, Cameron McCormack wrote: I'm still working on sXBL support for Batik and again I'm wondering about how separate code for 1.2 features should be. A few particular issues: Yes, all good questions. See answers inline. I'm still thinking about possible alternate options, but right no

Keeping SVG 1.2 code separate from SVG 1.1 code

Hi Thomas and others. I'm still working on sXBL support for Batik and again I'm wondering about how separate code for 1.2 features should be. A few particular issues: - What should be done for DOM 3 support? Should the existing classes in org.apache.batik.dom be updated with DOM 3 methods