[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] DOM or SAX: Sense and Sensibility
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
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.
From: firstname.lastname@example.org [mailto:email@example.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.