On Mon, 26 Nov 2001, Duane Maxwell wrote: [snip]
I also think that we should choose one of the extant XML parsers as well and have a known base from which to develop XML-based stuff (SOAP/XML-RPC, RSS, whatever). I will not be suicidal if the choice is not the one I wrote, though I would be willing to expend the necessary effort to address any weaknesses and/or extend it to fit the needs of the Squeak community.
You're probably right.
Actually, the *parser* isn't nearly as important as what it generates, since most of the time you'll be working with the parse tree (or event stream, or...).
Let me put in a word for the VisualWorks one...it's probably the most complete. It would let us share work with the VisualWorks and the Camp Smalltalk communities (and with Cincom itself). Cincom is definitely all the way behind it (they're even putting together some (hork) XML Schema stuff). I'm pretty sure they're open sourcing all bits, so we have an XSLT processer, XPath support, etc.
OTOH, we could be generous with our parse tree representations and parsimoneous with our parser. IIRC, the VisualWorks code has enough support to make generating varient Parse Trees pretty easy.
For a lot of apps, directly generating the application objects is the way to go (instead of parsing to some XML heavy representation and then working off that). Perhaps we should work in some modest thin level SAX like layer first, and then build/port other stuff on top?
On the downside of the VW one...the name choices for the various parse nodes is...ugly. Hideous even. Actually all the names get pretty ugly because of the namespace munging. But the Cincom guys seem pretty open to feed back, so we could evolve it in partnership.
The other possibility, of course, is to work with the Cincom guys to make their XML extras (XSLT, etc.) more independant of the parser...I don't know.
Masashi Umezawa has some fixes and smoothings to the current port which I'll be, well, moving to when I get a chance :)
Anyhoo. blather blather.
Cheers, Bijan Parsia.