- From: Joseph Kesselman <keshlam@us.ibm.com>
- Date: Mon, 25 Feb 2002 13:57:30 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: www-dom@w3.org
>Uhh, it *has* happened. Portability is "broken" in the Java/DOM world >because JDOM and dom4j have to be taken into account already. And the php >binding on top of the libxml DOM only vaguely resembles the DOM ... There's a major difference between someone else proposing a specialized alternative to the DOM within a limited problem domain where interoperability isn't an issue, and the DOM itself deciding to give up on interoperability. If we do that -- modulo the places where we explicitly left things as optional -- it isn't a standardized API and we might as well can the whole effort. If you want to design a Java DOM whose NodeList or NamedNodeMap also inherits compatability with of one of the Collections, and can do so without breaking the behavior of any of the DOM interfaces, that's fine. Code which takes advantage of that will be nonportable, but you won't be violating the contract imposed by the DOM API. Once you start talking about selectively implementing APIs and completely replacing them with others, you're talking about a custom API rather than being compliant with the DOM spec. There are times when a custom solution, or partial DOM compatability, are entirely reasonable. But don't expect the DOM to bless that usage; if you don't comply to the spec, you aren't a DOM. ______________________________________ Joe Kesselman / IBM Research
Received on Monday, 25 February 2002 13:58:08 UTC