From markup to object model   Table of contents   Indexes   Managing tokenizers in XML search
 

Programming XML: using the DOM

 Wood, Lauren 
 
 Lauren  Wood
 Director of Product Technology
  British Columbia 
 Canada 
 SoftQuad Software Inc. 
 Surrey 
SoftQuad Software Inc.,  108-10070 King George Hwy
Surrey  British Columbia  V3T 2W4 Canada web site: www.softquad.com email: lauren@softquad.com
Phone: +1-604-585 8394 Fax: +1-520-569 2382
 Biography
 Lauren Wood - Lauren Wood is Director of Product Technology at SoftQuad Software Inc. She plays a major role in the design of SoftQuad Software¹s HTML and XML authoring tools, as well as being a popular speaker at industry conferences. Lauren is Chair of the XML Document Object Model Working Group and has been an active member of the CSS and Formatting Properties Working Group, the XML Working Group, and the XSL Working Group. She holds a Ph.D. in theoretical nuclear physics from the University of Melbourne, Australia.
 

Current status

 The Document Object Model, Level 1 , became a W3C Recommendation on October 1, 1998. Since that time, it has been implemented in several different software products, both free and commercial.
 The Document Object Model, Level 2 , was at the time of writing very close to being a Proposed Recommendation. This is the final stage before becoming a Recommendation, and is the stage when W3C member organizations are invited to review the specification. This talk will mostly concentrate on what is new in the Level 2 DOM.
 The DOM Working Group is currently working on Level 3. The requirements for this were in the final stages of preparation at the time of writing, and are available on the W3C site, as are the other documents mentioned here. A brief summary of what is expected in Level 3 will be given in this talk.
 

DOM Level 2

 

Core

 The DOM Level 2 Core supports some new features. One of the most important of these is the support for namespaces . The new methods are the equivalents of the DOM level 1 methods, but with added namespace parameters. For example, createElementNS(in DOMString namespaceURI, in DOMString qualifiedName). There are, of course, also the equivalent methods for creating attributes with namespaces, and a getElementsByTagNameNS method which returns a NodeList of elements with the given local name and namespace URI.
 Since the Core module is mandatory to claim DOM Level 2 compliance, all features from DOM level 2 on assume namespace support. For this reason, the new createDocument and createDocumentType methods have namespace parameters.
 There are a few other methods which have been added on request; for example importNode allows cloning a Node from one Document to another. getElementByID has been moved from the HTML module to the Core module, since it is a generally useful method.
 

Range

 The Range module is a set of higher-level methods to enable easier editing of a document. You can think of a range as being analogous to a user selection in a GUI, but mapped to the actual document tree. There are methods for deleting a Range, surrounding a Range with an element, or inserting content at one end of the Range. Ranges always fix themselves up according to specific algorithms to ensure the ensuing document is well-formed. The Range is defined in terms of the boundary-points of a Range, which occur within a container at a specified offset.
 

Events

 The events module contains a generic events framework for use with several event sets, as well as some specific event sets. The framework must be implemented to claim events compliance; the events sets are all optional.
 Each event has an EventTarget toward which the event is directed by the DOM implementation. This EventTarget is specified in the Event's target attribute. When the event reaches the target, any event listeners registered on the EventTarget are triggered. All EventListeners on the EventTarget will be triggered by any event which is received by that EventTarget, but there is no guarantee as to order.
 There are two types of event flow - bubbling and capturing. Event capture is the process by which an EventListener registered on an ancestor of the event's target can intercept events of a given type before they are received by the event's target. Capture operates from the top of the tree down, mostly starting at the document object itself. Bubbling works in the opposite direction - after the event is dispatched to its target EventTarget and any event listeners found there are triggered, bubbling events will then trigger any additional event listeners found by following the EventTarget's parent chain upward, checking for any event listeners registered on each successive EventTarget. This upward propagation will continue up to and including the Document. With the combination of both of these flows, an event can be triggered anywhere in the document. The stopPropagation method can be used to stop the event flow.
 The events themselves have context to be used when carrying out the action specified once the event happens. The context varies from event set to event set. For example, in the mouse event set, the context includes the screenX and screenY coordinates of the mouse action. In the mutation event set, the context includes a related node, which, depending on the precise event, could be the parent of the node which was changed.
 The event sets which are specified as part of the Level 2 DOM are UI, mouse, mutation, and HTML. The key event set which was in earlier drafts had some internationalization problems and will now be in Level 3.
 

Traversal

 The Traversal module enables easier ways of walking through the document tree. It defines two new constructs - a NodeIterator and a TreeWalker . These both present a logical view of the tree, which may not have all the nodes in it which are actually in the document tree. The NodeIterator is a flat view of the tree, in which there is no parent/child relationship. Thus methods enable moving forward or backward in the list, but not up and down. The TreeWalker, in comparison, retains the hierarchy of the original tree, even though some nodes may be missing, and therefore has methods to move up and down in the tree as well as back and forth.
 Both NodeIterators and TreeWalkers will adjust themselves automatically to changes in the underlying tree.
 There are two ways of determining which ndoes are to be visible in the NodeIterator and TreeWalker. There is a whatToShow flag, which has values to determine whether, for example, comments are to be shown. Children of nodes which are not to be shown may still be shown; this is useful when the entity reference nodes present in the tree are to be treated as expanded and not present, for example. The more flexible method of determining which nodes are to be visible, which is used in conjunction with the whatToShow flag, is the filter. Filters allow the user to create objects that "filter out" nodes. Each filter contains a user-written function that looks at a node and determines whether or not it should be filtered out.
 

CSS

 The CSS module is designed to allow association of CSS stylesheets with documents, as well as accessing and setting individual CSS properties within a stylesheet. Interfaces are provided for each specific type of rule in CSS2 (e.g. style declarations, @import rules, or @font-face rules), as well as a shared generic CSSRule interface. There is also an optional interface which provides shortcuts to the string values of all the properties in CSS level 2.
 

DOM Level 3

 The Level 3 DOM will contain the following modules:
 
  • Content models and validation - including document editing guidance, editing of DTDs (and potentially schemas), and namespace checking
    •  
  • Load and save
    •  
  • Key events
    •  
  • Views and Formatting - how the DOM knows that a user interface exists (if it does) and what properties are associated with it
    •  

    Other DOM-based APIs

     Several other groups are designing APIs which incorporate the DOM. These include
     
  • Mathematics Markup Language
    •  
  • Scalable Vector Graphics
    •  
  • Synchronized Multimedia Language
    •  See for more details.
     

    Demos

     The demos will be chosen by the speaker closer to the session, to ensure getting the latest in the world of DOM.
     

    Resources

     Some useful resources can be found at
     
  • The DOM page http://www.w3.org/DOM at the W3C site
    •  
  • Robin Cover's DOM pages http://www.oasis-open.org/cover/dom.html
    •  
  • The Open Directory Project http://dmoz.org/Computers/Programming/Internet/W3C_DOM/
    •  Bibliography
     
    DOM1  http://www.w3.org/TR/REC-DOM-Level-1
     
    DOM2  http://www.w3.org/TR/DOM-Level-2
     
    DOMRequirements  http://www.w3.org/TR/DOM-Requirements
     
    Namespaces  http://www.w3.org/TR/REC-xml-names
    From markup to object model   Table of contents   Indexes   Managing tokenizers in XML search