No, I've written applications using both the SAX and DOM interfaces of the MXML parser. I actually rather like it. But there are limitations, such as being restricted to 7-bit ASCII and problems with TCP/IP streams. My application have always read and written host files, and I've found that it has worked quite well in those situations. Of course, there is much that I'd like to see that isn't there, notably XSLT and namespace support, not to mention document validation. (The last of these is more of a "nice to have", though, because if a document doesn't conform to the schema, that will be discovered soon enough while parsing the document.) The ugly thing, though, is that I've basically had to create my own non-standard templates to drive the parsing process (as an alternative to coding a parser from scratch for every conceivable document type). I've been looking at solutions to this last problem (such as XOM and XML data binding), but this is really orthogonal to the issue of parsing XML in an efficient and robust fashion.
--- Jim Self <[EMAIL PROTECTED]> wrote: > > I assume that you are referring to problems in an XML implementation > currently in VistA. > Do you need help in debugging that or writing something better? > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
