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 much). I suppose one could bundle DOM2 and SVG 1.1 jars that people could compile against. What do you think?
I don't know if there would be much demand for ensuring that Java programs people make use only SVG 1.1 features. Are there situations where SVG 1.1 only Batiks are installed that can't easily be upgraded (on web servers or something)? I don't think people will deliberately restrict themselves to SVG 1.1 features if the Batik they are using supports SVG 1.2.
You are correct that the number of people who are likely to want/need this are small. So it probably makes sense to keep this in mind if anyone ever asks about it, but not to bother including the jars with Batik.
As for throwing exceptions, this would be the easiest solution, but is checking for version for every 1.2-specific method too much overhead?
I would doubt it, but I don't really know DOM 3. It is possible that something like 'nextSibling' (from DOM 2) might be fast enough that the extra check would be noticed. However, I think in general if the document stores an integer indicating 'version' the check should be very quick relatively speaking.
BTW the xml-apis in JDK 1.5 is DOM 3 :/
Is compilation or execution affected by this at all? (I haven't tried JDK 1.5.)
I don't think execution is affected (interfaces are funny as long as you don't try and call an 'unimplemented' method you're OK). This does make it impossible/very difficult to compile with the JDK 1.5 compiler, because the compiler does check that all methods are implemented (otherwise the class needs to be marked as abstract) and we don't implement all the DOM 3 methods. So you would have to do something odd to get the DOM 2 xml-apis in the classpath before the JDK's DOM 3 copy.
However I suspect that in the fullness of time it will be best to just add NodeXBL to the 1.1 impl (*sigh*).
The only XBL-ness in the SVG subclasses are in the SVGDOMImplementation and
SVGOMDocument, to create XBL* objects.
What all is in the NodeXBL interface?
A couple of other classes in there too, but they probably belong in the svg12 package (SVGOMCustomElement, SVGOMXBLTemplateElement).
Yes, these should probably be in the SVG12 package.
What 1.1 elements behave differently in 1.2, if any?
Just about all of them, since the SVGLocatable interface was expanded. Normally people would consider an implementation to be in error if it allows calls to methods that aren't defined in the specification it implements.
Anyway, maybe you should weigh in to that thread with your opinion.
I'll do that.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
