Cart
[Home] [By Thread] [By Date] [Recent Entries]
This is a serious issue. Here are a few thoughts... I'm not promising anything more than that :-) I've found that SAX is anything but obvious to the programmers I've worked with, even programmers with extensive GUI experience (people who have actually built a GUI framework don't have any problem). And even after being pointed to SAX they don't always have much of an idea of how to proceed. This isn't entirely their fault. We have nice frameworks for dealing with events generated by GUIs. With SAX there is no such thing, that I'm aware of. The developer is faced with a stream of events and no framework for dealing with them. Yes, I know that you can quickly put something together but I've been doing that for years, not every one has. What's the consequence of getting it wrong? Serious trouble. You end up with slow, ugly, unmaintainable code. Worse, I've seen developers using the resultant mess to avoid using XML altogether (we really are still in the early days of XML). A little, real-life, example... Consider an XML based specification of some events and their response (not SAX events, but application events). The code that interprets the XML file was using a DOM representation, and it wasn't great code -- someone's first attempt at using the DOM wound up in the product (that's another issue). What happened? It was felt that the amount of code, and the obscurity of that code, makes XML unsuitable and unsafe for this task, this task being 'application configuration'. The question of how this should have been done never was asked. The end result was replacing the nice little human readable XML file with a complex database, with something like nine tables, that is maddening in its difficulty to set up and impossible to for a human being to understand. Worse, every other configuration file was also moved out of XML into the database. Yes, there was politics involved, but still... The system I was working on has a different issue: neither SAX nor DOM is quite right. You want an in-memory representation of a collection of 'documents' but the DOM is too 'distant' -- the DOM is about the document, we needed something else. I wound up writing an XML data binding (didn't know it was called that then :-) This was *really* easy to get all the developers in my group (about 17) using this. As a matter of interest, recently I've use the pull-parser XPP. I have a suspicion that this reversal of control flow will make it easier for a lot of people to work with event based processing. Personally, I think I still prefer SAX. I could go on... Cheers, Bob On 01/11/07 12:23 PM, "Bullard, Claude L (Len)" <clbullar@i...> wrote: > A topic for the usual Friday introspection two > days early: > > How often do you as experienced XML developers > find people in your shop using DOM for work > more appropriate to SAX? Have you asked > them why and what do they say? What are the > costs of picking the wrong API? > > len
|
