- From: <keshlam@us.ibm.com>
- Date: Wed, 10 Nov 1999 10:02:44 -0500
- To: David Brownell <david-b@pacbell.net>
- cc: www-dom@w3.org
>> Note that the same result can usually be accomplished (in Java, at least) >> by declaring a new set of interfaces, in the new package, which inherit >> from and override/extend the standard DOM API. >That's only "the same result" at a technical level, when the interface is >intended to be compatible ... things like "improved" APIs (lighter weight, >perhaps server oriented, removing perceived misfeatures) are precluded. At that point you're talking about nonconforming implementations. The way I'd recommend dealing with that is to implement the DOM API as it stands but throws a DOMException (NOT_SUPPORTED_ERR, NO_MODIFICATION_ALLOWED_ERR, or whatever's appropriate) whenever necessary. Again, that avoids the need to modify the existing interface. The upside is that you can reuse code which references these calls but in your application never actually invokes them. The downside is that if it _does_ invoke them, you only find out about this at runtime. (I did exactly this recently, when we needed something which was DOM-compatable but had constraints that kept it from being fully DOM-compliant.) ______________________________________ Joe Kesselman / IBM Research
Received on Wednesday, 10 November 1999 10:03:09 UTC