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. As for throwing exceptions, this would be the easiest solution, but is checking for version for every 1.2-specific method too much overhead? > 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.) > This is in fact potentially more manageable as ANT could be > used to create two copies of dom.svg one where classes inherit from > XBLElement and one where they inherit from AbstractElement (assuming > that there is little or no XBL-ness in the SVG subclass). 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. A couple of other classes in there too, but they probably belong in the svg12 package (SVGOMCustomElement, SVGOMXBLTemplateElement). > I'm a little less sure here, but given we added 1.2 to > everything else unless there are significant 'incompatibilities' > I'd be tempted to just have one set of event classes. I'm a little > surprised that you don't need XBL stuff in EventSupport anyways. Yeah, I was trying to keep it out of EventSupport, but on reflection I probably will just have to use a subclass for 1.2 documents. > I think the proposal that the 'version' attribute can be > change (and modify document behavior) is ridiculous. What is the > usecase? If it were free then fine but it will be far from free for > all implementations (at the very least requiring a walk of the tree - > looking for now invalid things) and there really isn't a single good > usecase I can think of. I guess it is a lot of work for something that nobody will ever do. > Let's take the case of an existing reference to a node it > suddenly needs to lose/gain it's SVG 1.2ness? seems silly to me. I was trying to think of some cases where this would be troublesome. Is it really a problem if DOM 3 methods exist on 1.1 DOM objects (provided they throw exceptions)? Certain script could execute differently by just checking if a function exists on the object or not. But I guess if you are writing a 1.1 document and it refers to a DOM 3 method then any behaviour would be (strictly) acceptable -- if it is a function reference or a the undefined value, it shouldn't make much difference, practically. What 1.1 elements behave differently in 1.2, if any? Anyway, maybe you should weigh in to that thread with your opinion. Cameron -- Cameron McCormack | Web: http://mcc.id.au/ | ICQ: 26955922 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
