Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been trying to understand the DOM, and although I have a fair idea of what it is, there are certain ideas I just cannot pin down. I will list down what I think the DOM is and my questions will be inline.

  1. The DOM is a fully object-oriented representation of the web page. The W3C DOM standard forms the basis of the DOM implemented in most modern browsers.

    So does the DOM talk about how an XML/HTML document is represented as an object model?

  2. The DOM does not specify that documents must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented.

    In what other ways can the document be represented?

  3. When you do something like this -

    document.write('welcome to my home page!');
    

    the document object is provided by the DOM. The write methods are the interfaces that are exposed to JavaScript by the DOM.

    So the objects and its methods are created as JavaScript objects by the DOM parser and then presented to the JavaScript engine? Or are the objects and methods within the DOM parsing engine in their own native language? And is exposed to the JavaScript engine? If this is so, then what is responsible for translating from JavaScript to the native language?

  4. What are language bindings ?

    The language binding is the set of objects native to the language in question that implements each of the interfaces in the DOM specification.

    Developers can create language bindings from the DOM to their language simply by following the IDL (Interface Definition Language) in the DOM specification.

    So if the DOM parsing engine is implemented in say C++, does that mean that when you create language bindings by following the IDL, you are just creating objects in the specific language, i.e C++ that your DOM parsing engine is built with?

share|improve this question
    
@apsillers It should have been "So does the DOM talk about how an XML/HTML document is represented as an object model?" I have edited the post. –  user1720897 Jun 3 '13 at 13:55
    
I'll answer what I can in the comments. 3 & 4 might take someone who develops browsers to really answer and I don't want to affect the answer count. 1 - the browser has an understanding of the current state of the document, you can call this the DOM, alternately you can call the DOM the standard interfaces that it exposes that allow you to query and modify the state of the document. –  George Mauer Jun 3 '13 at 15:00
    
2 - The statement is about implementation, not representation. Unless I'm mistaken, the ''representation'' does have to be a tree. The behind-the scenes implementation does not. –  George Mauer Jun 3 '13 at 15:01

1 Answer 1

What follows is my best reading of the relevant specifications and references. (I found Mozilla' abstracts about DOM levels and associated links especially helpful.) I encourage corrections or clarifications from others.

So does the DOM talk about how an XML/HTML document is represented as an object model?

Yes. There are two parts to DOM Level 1 specification -- Core and HTML. The Core DOM specification describes a general DOM that could be used to represent any structured document. The HTML DOM specification describes how to use the Core DOM to describe HTML documents specifically and includes HTML-specific interfaces.

The DOM does not specify that documents must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented. In what other ways can the document be represented?

DOM Core does assume that the document is a tree. The Node interface is the "...primary datatype for the entire [DOM]. It represents a single node in the document tree." Node has several properties for accessing children, sibling, and parent nodes (e.g., parentNode, frstChild, etc.) that implies a tree structure. You could use a flat tree or a linear tree (e.g., a linked list), but it's still going to be some form of tree.

As George Mauer points out in the comments, perhaps you mean that the underlying model of an particular implementation does not need to be a tree. That much is true; as long as your implementation provides the functionality promised in the DOM specification, you can use whatever structure you like to provide that functionality.

Are the objects and methods within the DOM parsing engine in their own native language?

Generally, yes. In most browsers, the DOM is implemented in a lower-level language like C, and the browser supplies bindings to the JavaScript environment that can manipulate the actual representations. In fact, if you look at the question Meaning of “Moving DOM into Javascript”?, you'll see that Google is interested in switching to a native JavaScript DOM implementation (likely to avoid needing both a C++ function and a duplicate JavaScript wrapper for that C++ function; possibly also for performance gains).

what is responsible for translating from JavaScript to the native language?

I'm a little bit hazier on this subject, but my understanding is that when a JavaScript DOM binding is invoked, the JavaScript execution environment (which is itself implemented in a lower-level language like C) makes a call to the relevant DOM function (written in C/C++) to manipulate the DOM.

If you want to go deeper than that, you'll need to talk to someone who actually makes browsers.

does that mean that when you create language bindings by following the IDL, you are just creating objects in the specific language, i.e C++ that your DOM parsing engine is built with?

Yes. The DOM's IDL is language-agnostic, so that you can implement it in any language. "Writing a DOM implementation" means writing code (in a particular language) to conform to the IDL interfaces described in the DOM specifications.

share|improve this answer
    
I believe bindings would have to involve two things. Invoking the native run-time through references and some way to pick up events from the native implementation. You can actually see what methods are just native code wrappers in browsers by console logging them typically. e.g. console.log(document.write); or console.log(document.constructor); - add .toString() the log param in browsers that don't give you the function text. Objects wouldn't necessarily have a mirrored equivalent in the native code. Also, most DOM object properties are actually getters with associated behavior. –  Erik Reppen Jun 3 '13 at 18:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.