[
Lists Home |
Date Index |
Thread Index
]
9/20/2002 7:07:41 PM, Arjun Ray <aray@nyct.net> wrote:
>--
>Interoperability means that I can call my barber to make an appointment
>and not have to concern myself with what telephone carrier he's using or
>who manufactured his phone. It doesn't mean that I can call my barber,
>order a pizza, and expect to have one delivered. -- Eric Bohlman
In the original worldview of the DOM, in the long ago days of 1997, people
had a quaint notion that it should be possible to write Dynamic HTML that
worked the same way in all browsers. This Dynamic HTML might be written
in Javascript, in Java applets or ActiveX controls, or in some language
nobody had heard of but that would emerge in Internet Time. The idea was to
minimize the gratuitous differences among these languages via a
common object model and API. Also, since the same basic code might
be moved to server-side servlets, ASP pages, etc. with *relatively*
few changes to the overall logic, a single object model would be useful
for both client and server applications.
People also had the even more quaint notion that Dynamic HTML would soon
be replaced by Dynamic XML, so up-front work should be done to smooth
the transition from HTML to XML, so the two should share as much of
the OM/API as possible. From my corporate perspective of that bygone
era, I was hoping that the DOM-based "dynamic XML" apps written for the
standardized browser platforms would be easily portable to XML editor
environments (I worked for Arbortext at the time).
So, in those long-lost days when we saw the
web as having infinite possibilities rather than overwhelming legacy
constraints, the DOM vision made a lot of sense. Of course, things haven't
worked out that way ... there is only one browser vendor worth considering
from a business perspective, so there is a negligible business advantage
from building to a standard API. Once the browser wars ended in a
rout, there was no incentive for the victor to support the idea of
interoperable APIs. The whole idea of interoperable Dynamic HTML for all
but the simplest applications pretty
much withered; its ecological niche is now filled by Flash.
Likewise, for whatever reason, HTML did not get replaced by XML on the
client side, so there's a more or less negligible market for standards-based
interoperable Dynamic XML.
That's what I meant by standard APIs being "unfashionable" (or whatever I
said in the version actually sent to the list). I agree with Eric that
people SHOULD care about API standards, but they don't. I wish the original
assumptions -- that there would be browser diversity, that API standards would
be considered important, and that XML+CSS+DOM would be the dominant
light-client application platform -- had become reality. They
didn't, so be it ...
Still, many of the basic DOM application design patterns can be transferred
to server-side Java/Python/PHP+XSLT -> HTML, or client-side Flash (Flash
MX supports a minimalist DOM-like API), DOM-based Dynamic XML apps that run in
XMetaL or Epic (and to a limited extent IE and XML Spy). The ability to
move Java DOM applications between Xerces and Crimson (and perhaps other
parsers/DOM environments) gives users some real options.
It hasn't by any means been a waste, even if the current reality is
that API standardization doesn't buy most users a whole lot.
So, given that the constraint of maintaining API-level doesn't offer much
benefit in return for its costs, it's time to experiment and refactor.
If that refactoring exposes some hidden costs of other XML standards, their
contracts ought to be reviewed rather than automatically renewed too.
[I hope it's obvious that this is my humble PERSONAL opinion and not that
of my current employer, former employer, or any entity of the W3C.]
|
