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

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

I keep hearing that last bit too.  "I'll pass you a 
DOM; it gets a DOM" and so forth.   In one room, 
I tried to explain what the infoSet was and why one 
might want to know about it and the programmer replied, 
"I don't want to know that.  Useless.  Show me the code." 
The scary thing is this stuff is coming out of interface 
experts.

Are the XML abstractions that hard to learn?  To me, 
regardless of other issues, the infoSet description 
has always been an easy read and explained how the 
structural abstractions made the meta-ness tractable 
in the APIs.  I'm not sure it is all that easy to 
understand XML without it, but I'm poisoned fish 
anyway after two decades of markup work.

len

-----Original Message-----
From: david.hunter@mobileq.com [mailto:david.hunter@mobileq.com]

Without any hard data, here are some reasons I suspect come into play when
people choose the DOM over SAX, when SAX might be more appropriate:

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.

2)  Unfortunately, programmers [including myself] often test their code with
much smaller data sets than they can expect in real life.  One of the
reasons one might choose SAX over the DOM is that one is working with very
large XML documents, but if one is not testing one's code with large
documents, one might not realize one needs SAX until it's too late...

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.