Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Bullard, Claude L (Len) [mailto:clbullar@i...] > Sent: Wednesday, November 07, 2001 2:34 PM > To: Al Snell > Cc: xml-dev@l... > Subject: RE: 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.
|
