Re: Walking the DOM (was: XML APIs)

>Then if somebody takes our application and replaces our hacked DOM class
>library with a ``real'' one, the performance will go to blazes and we'll
get
>the blame.

Two solutions, at two different levels.

1) Don't promise your class is DOM-compliant. Just say it's DOM-like.
That's essentially what you proposed when you said:

> implement the interfaces in the obvious way, and put disclaimers in the
> comments to the effect that ``this application implements the DOM
> interfaces, but not all of the specified behavior.''

If someone replaces that with a real DOM, it's their responsibility to
reconcile any behavioral differences. Of course this may cost you some
customers for whom DOM compliance is an issue. Your call.

2) Performance differences between DOMs are going to exist.

If folks find a DOM is too slow for their application, they should shift to
one that responds better for their application. That may mean a DOM that
made absolutely no effort to optimize things they aren't using in favor of
screaming performance on those they are, which ought to be something you
could do with your tuned version. If they use one of the detuned features
in yours, performance will fall like a stone... just as if they are relying
on something yours does particularly well, switching away from it may have
the same effect. But if the detuned routine (eg a NodeList with absolutely
no caching) eventually returns the right result, you're still a valid
DOM... just a specialized one. The customer gets to decide what's
overspecialized and what's overgeneralized, based on their own needs.

Or, to put it in more succinct form:

>Something that is impossible to implement efficiently is not
>going to get used very much.

In which case, you won't have to worry about implementing it very
efficiently. Which will further discourage folks from using it when running
against your DOM. Hazard: It may discourage them from using your DOM at
all, if their priorities don't match yours. Your call, again.

>the principle of ``least surprise.''

Agreed, it's a very good rule to live by. Sometimes engineering concerns
conflict with it, sometimes marketing concerns conflict with it, sometimes
there's disagreement about what's least surprising. And sometimes "least
suprise" means "interoperates with everyone else, even if I disagree with
the shared behavior and hope it changes at some point in the future."
______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Wednesday, 4 November 1998 11:30:37 UTC