The DOM Core Defined

At this point, we've examined in detail the DOM Core Level I and Level II interfaces to understand how they are used. However, we have glossed over how the DOM Level I and Level II are actually specified. In this section, we examine this issue in detail and see that DOM interfaces are specified using something known as the Interface Description Language or IDL. After all, seeing the Java descriptions is good, but sometimes we want to go right to the source.

The concept of IDL gained popularity a long time ago, in computer terms anyway, with Sun-RPC. More recently, CORBA has built on past work to create a concise IDL standard. DOM interfaces are defined using the common CORBA IDL syntax. For the most part, IDL is fairly easy to read and we won't get into CORBA specifics. The interested reader can refer to Chapter 13 of Java 2 and JavaScript for C/C++ Programmers, (Daconta, Saganich, Monk; John Wiley and Sons, 1999) for a better understanding. However, because the DOM Specification is written in IDL, there are a few conventions you should be aware of. Three of the more useful ones are noted here.

• interface name: parentclass { .... }; Defines a new interface name that extends parentclass.

• [readonly] attribute type name; Defines a variable name of type type. Defines an attribute (member variable), that may be read-only and results in get/set methods being defined.

• For example, readonly attribute DocumentType doctype; also defines the java method DocumentType getDoctype();. Note that attributes marked read-only do not define a set method.

The third IDL syntax convention supports defining methods. For example

					type methodname([in/out/inout]arguments...) raise(someexception)
				

specifies a method methodname, returning type type with the specified arguments (which can input/output or both), which may cause an exception. For example, the Document interface defines a method for creating attributes:

					Attr createAttribute(in DOMString name) raises(DOMException);
				

These are only three of the many important syntax definitions in IDL. Many more exist for defining objects within packages and specifying scope and a variety of other language constructs. We needn't go any further with CORBA at this point except to understand one additional aspect. Normally, an IDL definition is processed via an IDL compiler and results in a language-specific binding for a given definition. Earlier, we stated that a definition results in methods getting defined. What actually happens is that when the IDL compiler is executed, the interface definition generates language-specific code (Java-specific code, for example). All the definitions are processed and so-called mutator (get/set) methods are generated for attributes and the like. As we can see, IDL does not really "define" methods per se but is close enough for our purposes.

Listing 3.10 shows the complete IDL definition of the DOM Document interface (with line numbers added for clarity).

Code Listing 3.10. IDL Definition of the DOM Document Interface

1    interface Document : Node { 
2        readonly attribute DocumentType doctype;
3        readonly attribute DOMImplementation implementation;
4        readonly attribute Element documentElement;
5        Element createElement(in DOMString tagName)
6           raises(DOMException);
7        DocumentFragment createDocumentFragment();
8        Text createTextNode(in DOMString data);
9        Comment createComment(in DOMString data);
10       CDATASection createCDATASection(in DOMString data)
11          raises(DOMException);
12       ProcessingInstruction createProcessingInstruction
13                             (in DOMString target, in DOMString data)
14            raises(DOMException);
15       Attr createAttribute(in DOMString name)
16           raises(DOMException);
17       EntityReference createEntityReference(in DOMString name)
18           raises(DOMException);
19       NodeList getElementsByTagName(in DOMString tagname);
20  } ;

If we examine it closely it can be analyzed as follows:

Line 1 defines the interface Document that is derived from the interface Node.

Lines 2, 3, and 4 define four member variables, all of which are read-only and result in the getDoctype, getImplementation, and getDocumentElement methods being generated when the IDL is processed.

Lines 5–18 define methods for creating child objects.

Line 19 defines an additional method that returns an ordered list of nodes of type tagname.

And that's all there is to it! IDL is fairly clear to Java developers. CORBA is well suited to Java and maps well to Java syntax. For a larger taste of IDL, refer to any of the W3C Java language binding specifications.