There is one very nice feature of using XML as a protocol, that I haven't mentioned yet: Standard XML (like BSML or CML) is viewable via Web browser...it will someday be almost as common as HTML. So, if TULIP uses BSML and CML, then TULIP tool communication over the Web via HTTP (to browsers or other tools) will be rather simple. Imagine a TULIP tool that may only run on an SGI, and that tool being able to communicate with other TULIP tools on a Linux box, simply via HTTP. (Of course, you may argue that you can set up tools across a network many other ways, but you can't without an account, etc...this is the whole reason why the Web is so popular.) Here is my argument for using XML with TULIP: Premise: (1) All complex communication requires a structured protocol (2) TULIP ought to have a protocol that is established (3) TULIP ought to have a protocol that is language-independent (4) " " " " " " " " platform-independent (5) XML is an established, language-independent, and platform-independent structured protocol...plus it is (inter)net-workable, as I wrote above. Conclusion: TULIP ought to use XML. If anyone has a better idea, let me know. I think XML was developed for our kind of problem. Sure, all communication via stdio and ASCII will be slower than with other options, but when the tools all run on the same machine, we won't know the difference...we're not talking about the constant updating of information anyway; it will be requested only when the user presses some button...like a Web browser. But don't miss this point I made once before: TULIP tools may behave like browsers by using XML, but they won't just display hypertext; that's HTML's job. We can use BSML and CML to make some very non-Web-browser type interfaces, that are very interactive. Jeff -- J.W. Bizzaro Phone: 617-552-3905 Boston College mailto:bizzaro at bc.edu Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/ --