Re: [xml-dev] DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM

[Robin Berjon <robin.berjon@expway.fr>]

On Mar 31, 2006, at 20:15, Tatu Saloranta wrote:
> This used to be one of main selling points for DOM
> (raison d'etre, even) -- no matter the language, you
> know the API. I thought it was an urban legend (portal
> theory for coders), but I guess it isn't. ;-)

It is an urban legend. How you use the DOM varies not only from  
language to language but also from implementation to implementation.  
It's not so much that they don't interoperate, but rather most have  
this or that shortcut that you'll use -- except perhaps in the only  
case in which interoperability across DOM implementations matter,  
which is to say in the browser.

> > I think it's worth pointing out at this stage that
> > JavaScript
> > programmers don't appear to seek or design
> > alternatives to DOM at all.
>
> Part of the reason of which probably is that, since
> DOM  was created FOR Javascript (standardized what
> Netscape had built for its needs)

No, I don't think that's true. If the DOM had been created for  
Javascript it would be a *lot* less horrible than all the hoops it  
had to jump through to support utterly braindead languages like Java.

Also, if it had been about standardising what Netscape had built it  
would be a lot more horrible than it is. I believe much of the horror  
was due to having to support Java, and having to get Netscape and MS  
on the same page, which probably involved making some wrong decisions  
just to get consensus.

It's true though that in many languages the DOM is a lot less painful  
than it is in Java. If you have a language in which you can bind  
anything that's actually a list in the DOM to the language's native  
notion of arrays, and if you have a language that supports objects  
that know their own type so that you don't have to cast them five  
times every other line of code you find that using the DOM isn't all  
that painful. Throw in XPath, which the DOM WG started work on too  
late IMHO, and you've got something quite decent. I can't count the  
number of Perl programs I have that just rely on the DOM and XPath —  
they tend to look an awful lot like a bunch of XQuery FLOWR  
expressions, except you don't have to learn a new language and you  
have access to all the stuff you normally get from your language. I'm  
sure experiences in the rest of the OO and dynamic realm (Ruby,  
Python, etc.) are similar.

The reason alternatives to the DOM have not been all that successful  
for Java is because Java is all about cargo-culting and pain. Cargo- 
culting as in you throw IO exceptions when you write to memory,  
because it looks like what the other guys are doing (I don't even  
count those anymore), so if other folks are using the DOM you use the  
same, none of that crazy new stuff can possibly be any good. Pain as  
in if you've resigned yourself to need seven lines of code to open a  
text file for writing, honestly it's not the DOM that's going to  
scare you. Add to that the pain that adding an extra JAR brings, with  
all the deployment headaches, you certainly won't be much tempted to  
throw in XOM or JDOM.

--
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/