News Stay informed about the latest enterprise technology news and product updates.

DOM Level 2: Better than SAX?

Lauren Wood, chair of the W3C DOM Working Group, answers our questions about the DOM Level 2, and XML authority Benont Marchal, shares his thoughts on the DOM vs. SAX.

On Nov. 13, 2000, the World Wide Web Consortium (W3C) announced the recommendation of the Document Object Model...

Level 2 (DOM Level 2). Lauren Wood, of SoftQuad Software Inc., and Chair of the W3C DOM Working Group discusses the recommendation and what it means for developers with Assistant Editor, Catherine Ketcher.

SearchXMLresources: What is the Document Object Model Level 2?

Lauren Wood: The Document Object Model Level 2 is a way of accessing and manipulating XML, no matter where the XML comes from. It builds on the successful and widely implemented DOM Level 1.

SearchXMLresources: What does it mean to be a W3C Recommendation?

Lauren Wood: It means that W3C and the W3C member companies (there are now around 300 of them) agree that this is useful functionality that is stable and ready to be widely used. They recommend its use - this is where the name "Recommendation" comes from.

SearchXMLresources: How does Document Object Model Level 2 differ from the Document Object Model Level 1?

Lauren Wood: It adds to Level 1 functionality. Where, for example, DOM level 1 didn't have any namespace functionality, because the DOM level 1 specification was finished before namespaces were ready, DOM Level 2 adds the namespace support that's needed to use them. It also adds support for CSS, and events, so that you can now add interactivity to XML in the same way as people use dynamic HTML. There are ways of moving through the document quickly, and looking at just a part of the XML that you have, ignoring the rest. So it adds a lot of functionality that people have been asking for.

SearchXMLresources: DOM Level 2 now supports XML namespaces. Do you know of any concerns for developers to be aware of when using namespaces?

Lauren Wood: Be careful when moving parsed entities around that have unbounded namespaces - it's always safest to declare the namespace inside the parsed entity. This is because namespaces are scoped, so where a parsed entity is can determine what the elements and attributes inside it are if they have namespaces that are declared outside of the parsed entity itself.

SearchXMLresources: We now have an open standards programming interface to an open standards data format, which runs through a platform independent object oriented programming language. Would you consider this to be one of the greatest milestones in computer programming?

Lauren Wood: I guess I'm too close to it to be able to really judge the significance. I think this is very important, and it's something that hasn't been standardized before. Previous to the DOM and XML, everyone had their own way of representing data, and then their own way of manipulating it. So you're right, this is a milestone. I guess the computing history books in ten years will be able to judge the real significance of it.

What I'm happy about is that so many of the tools that people need in their everyday work now support XML as a standard, and the DOM as a standard way of accessing and manipulating that XML. Many tools implement these under the covers as well, the "XML and DOM as plumbing" approach, so people don't even know that they're there. I think in the future we will see more of this; XML and the DOM will become ubiquitous but invisible, just like plumbing in a building, which you generally don't even think about.

SearchXMLresources: The DOM Core APIs present two interfaces to an XML/HTML document - the object oriented approach and the Node interface. Can you explain to our readers when one approach should be preferred over the other?

Lauren Wood: It's really a question of what they feel more comfortable with. For many people, the object-oriented approach is more natural while others prefer not having to cast when using languages such as C++. Sometimes you need the extra functionality on the extra interfaces, sometimes you don't. It does depend on what you're doing - casting can be expensive in terms of performance so for those applications you'd probably use the Node interface as much as possible.

SearchXMLresources: What's the single largest issue that developers need to consider when moving from DOM Level 1 to DOM Level 2?

Lauren Wood: DOM Level 2 is more modular than DOM Level 1, so implementations won't necessarily implement all of the DOM Level 2 modules. Developers should use the "hasFeature" and "isSupported" functions to make sure that the features they need are actually there.

SearchXMLresources: What's your biggest complaint or downside concerning DOM Level 2?

Lauren Wood: It took quite a while to get out - but then that also means that we're confident that we've got the bugs out of it and that it's implementable. Lots of people have already implemented DOM Level 2, and we're looking forward to DOM Level 3.

We also spoke with Benont Marchal, software engineer at and noted author of "XML by Example" and "Applied XML Solutions." Ben offered his thoughts on why he thinks SAX, not DOM will emerge as the most important API for XML developers.

SearchXMLresources: Can you comment on what the DOM Level 2 will mean to XML developers?

Benont Marchal: To be honest, I'm not excited by this release. Don't get me wrong: the W3C did the right thing, it's a good release, the team has done a good job, etc. However the most important API for XML developers IMHO is SAX, not DOM.

DOM enjoys a special status because (1) it's the official, W3C-endorsed API and (2) it's relatively easy to learn. Most developers start with DOM. Yet DOM was designed for browsers and editors and it's not so good or efficient for most other applications. If I had to compare, I'm sure we're using SAX in 9 out of 10 XML projects. As developers become more familiar with XML, as they turn to more powerful applications, they find that DOM is good but it's not as flexible as they would like. It's not due to a faulty design from the DOM team, it's because the DOM was designed primarily for browsers.

Still, from a developer standpoint, what I'm most interested in is the namespace support. Although namespaces are popular, I think there are still many applications out there that would benefit from using it. It's good they've added support for it and I like how they've done it.

SearchXMLresources: Although the W3C has deemed the DOM Level 2 worthy of Recommendation, it appears that developers will continue to debate its usability in comparison to SAX.

For more information on the DOM L2 Recommendation, check out:
World Wide Web Consortium Issues DOM Level 2 as a W3C Recommendation (W3C)

For more information on using Sax:
Use the Simple API for XML: Try SAX for XML document processingit's faster and uses less memory than DOM (XML Magazine)

Dig Deeper on Development implications of microservices architecture



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.