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

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Wednesday, November 07, 2001 2:34 PM
> To: Al Snell
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] DOM or SAX: Sense and Sensibility
> 
> 
> Is XML just that hard to learn, 
> too obscure, too different, or is this just 
> ossification brought on by years of copying 
> code and not looking beneath? 

"Too obscure" is an issue. I think old-timers underestimate how bizarre
SGML-speak (or InfoSet-speak) sounds to the uninitiated. 

I think the "too different" and "years of copying code" reasons 
are the closest to the mark.  My take is that XML is quite different; most 
experienced programmers can handle the HTML paradigm, 
the DBMS paradigm and the OO paradigm, and XML is sortof all  and sortof
none.  It's HTML-like at the syntax level, but the familiar HTML tricks
don't work. It's OO-like (from DOM-like APIs anyway), but the objects are
abstract nodes rather
than concrete order/item/address/price/quantity things that OO
people are used to dealing with.  It's  DBMS-like in that it packages up
inter-related data that you can search for, add to,  update, delete ...
but you can't (easily) use the SQL/JDBC/etc. interfaces to do this.

The event processing paradigm is just plain foreign to most people who
haven't dealt with low-level grammars/parsers since college, which describes
the overwhelming majority of professional programmers, I suspect. (Hmmm,
maybe I'm wrong ... the low-level GUI APIs are event driven ... but I'll bet
lots of people can handle "OK/Cancel" button event handlers but would be
overwhelmed by the detailed thought required to write a SAX application).

There's a real chicken/egg problem here: The XML paradigm(s) are hard to
grok because there aren't lots of good examples around to intuit from, and
there aren't the good examples because the paradigm is hard to grok.  One
can dismiss this as "ossification brought on by years of copying code" but I
think that "Programming by Example" is in fact how most people do it, for
better or worse.  My pet theory on the explosive rise of HTML is it is very
easy to do "by example."  Sheesh, that's how I figured out HTML ... I'd see
a cool site, do a View Source, and deconstruct how they did it.  (I
distinctly remember the scales falling from my eyes ... "Oooohhhh ....
everything is done with tables within tables within tables within tables ...
that's how you control layout without any explicit layout commands!")

The way forward, IMHO, is in producing lots of good, clear examples of
when/how to use the various XML tools, and making it easy for developers to
find them.  That's hard when the cool stuff is now done with Flash,
server-side code, etc.  The trick is to find examples that are small enough
to be understandable without major investment, but "cool" enough to be worth
taking the trouble.  Books on XML application development should probably
focus less on explaining the obscure corners of the specs and more on
explaining the problems that XML lends itself to solving, the different ways
(SAX, DOM, JAXB ...) you can attack it, the tradeoffs among them, etc.