This makes it extremely hard to write Java code that: a) Allows users to link in their own XML parser that implements org.w3c.* and b) Mixes Level 1 and Level 2 XML parsers in the same VM. Yes, I know about DOMImplementation.supports, but I am sorry, this is a hack. I strongly suggest you hoist the new Level 2 methods into new interrfaces that extend the Level 1 versions. This could be done as simply as spawning off another package name, as follows: // note package name package org.w3c.dom.level2; public interface Attr extends org.w3c.dom.level2.Node, org.w3c.dom.Attr { public org.w3c.dom.level2.Element getOwnerElement(); } This allows me to do the more Java-esque test for extended functionality: public void f(org.w3c.dom.Attr attr) { if (attr instanceof org.w3c.dom.level2.Attr) { // use level 2 functionality here } else { // fall back on Level 1 functionality here } } For someone implementing a Level 2 parser, one can simply ignore the level 1 names as folows: import org.w3c.dom.level2.Element; public class MyElement implements Element { // implement union of Level 1 and Level 2 methods } I really really feel this is an important issue. I have personally written code that loads multiple XML parsers and in the face of Level 1 and Level 2 parsers, I see trouble. It is also not that far fetched to come up with scenarios where this can happen (a web server that loads independently developed servlets that each use a different XML parser). Thanks, DBReceived on Sunday, 24 October 1999 13:21:50 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:24:51 GMT