Bijan,
Well there's complexity and there's complexity. And there's various interfaces to manage that complexity.
Actually it's partly those interfaces that create the complexity. If you take the ExoBox parser then there's just an XMLNode. Period. Not a whole set of nodes with interfaces and relations to learn.
And dealing with missing functionality can be more complex than dealing with unneeded functionality.
Depends on your practical needs. I attempted to get all three versions (ExoBox, YaX, and VWXML) going with a simple XML file and while the simpler ones (ExoBox, YaX) worked out of the box, I got various errors with VWXML. I _think_ this is because the VWXML parser was trying to validate against a (non-existing) DTD - but that's exactly what I was talking about wrt complexity. Two of the three just worked. One did not. As a person who's just trying to read some XML file (which will be 99% of all common applications) it seems pretty complex to me that I have to figure out why one of the three just doesn't like this file. And now I _have_ to look at each of these interfaces and try to understand what's going on inside.
So, what do you put in the base image? What *are* we standardizing?
The simplest thing that could possibly work. Obviously ;-)
One reason to work with VWXML parse nodes, even given all their ugliness, is that you can easily port your application to VisualWorks or any Smalltalk that supports a parser that generates those nodes. And vice versa.
This seems like *some* sort of win to me :)
Again, it depends. I seriously doubt that the majority of users will primarily look at how well this stuff ports - and then, it doesn't seem like a big deal to me to port either the ExoBox or the YaX parser to VW. And that's exactly _because_ of their simplicity ;-)
Those people who are intrinsically concerned about how to port their stuff between VW and Squeak are completely free to use the VWXML parser. Those who don't are probably much better served with one of the simpler models.
Cheers, - Andreas