OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xml-dev] DOM or SAX: Sense and Sensibility



> From: david.hunter@mobileq.com [mailto:david.hunter@mobileq.com]
> Sent: Wednesday, November 07, 2001 11:28 AM
> To: clbullar@ingr.com; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] DOM or SAX: Sense and Sensibility

<snip/>

> 1)  A lot of programmers are not really used to event-based 
> programming, as
> used by SAX.  They're more comfortable working with an 
> in-memory object
> model than in keeping track of context as events are passed in, etc.

Yes, and the difficulty, here, is not just with the notion of event-based
programming, but with conceptualizing the design of a component as a
state-machine. I've found many developers have difficulty thinking in those
terms for whatever reason.

<snip/>

> 3)  For COM programmers, who use Microsoft technologies 
> extensively:  MSXML
> had [some] DOM support long before it had SAX support.  I 
> think a lot of
> programmers, who aren't XML gurus, just got used to the fact 
> that "this is
> the way you work with XML".  I've even heard people referring 
> to an XML
> document as "a DOM", which shows how deep the confusion can go.

The case of MSXML offers another good example of why many programmers use
the DOM. Microsoft's DOM includes integrated XPath support. Developers can
load XML into a DOM, then easily query the structure with XPath to extract
the data they are after. Switching to SAX adds substantial complexity to the
code, which now has to deal with state management strategies to keep track
of where it is in the document at any moment.

I've found many developers in the Microsoft world take the integrated XPath
support for granted and don't realize that it is not a standard DOM feature
(yet).