Syntax vs. the DOM

On Jun 4, 2008, at 16:17, Elliotte Harold wrote:

> And of all the things XML has brought to the table, about the only  
> one I can think of that is worse than namespaces is DOM. It's ugly,  
> inconsistent, memory-intensive, slow, thoroughly despised by users,  
> and frankly just hideous.

I'm not a fan of the design of the DOM, either. In non-browser  
applications, people have the luxury of writing their own XML tree  
models like you and I both have done.

In the case of browsers, though, the DOM is both the data model and  
the API, and the model and API is shared across implementations and  
has tons of scripts written against it. The value of having different  
browsers implement the same model and API and the code out there  
written against the API is so great that the DOM isn't going to go  
away in browsers. Trying to fix the DOM would probably do more harm  
that letting it be the way it is across browser code bases and the  
time axis inside a browser code base.

> To define a single model while allowing many different syntaxes is  
> precisely the opposite of what XML is about, and why XML has  
> succeeded.


It may be so in XML language design that doesn't target browsers, but  
in the case of designing languages that are primarily meant for  
sending content to browsers ((X)HTML, SVG and MathML), the purpose of  
the bytes on the wire is to get parsed into DOM. The scripting, style  
and rendering systems operate on the DOM data model. It is feasible to  
swap the parser from underneath a dynamic SVG renderer to an HTML5  
parser or to an EXI parser, but changing the tree model to something  
would not be feasible considering all the code that has been written  
to operate on the DOM (including scripting libraries "out there"  
beyond the browser's own code base). Even the XPath view to the data  
has to be implemented on top of the DOM model with its quirks.

Therefore, browser-targeted languages should be considered to be  
defined in terms of the DOM. Ignoring the DOM doesn't work. "Fixing"  
the DOM doesn't work, either, where existing code expects the DOM to  
behave as it behaves now.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 4 June 2008 13:57:50 UTC