Return-Path: Mailing-List: contact general-help@xml.apache.org; run by ezmlm Delivered-To: mailing list general@xml.apache.org Received: (qmail 23306 invoked from network); 11 Jul 2000 03:33:08 -0000 Received: from lotus2.lotus.com (192.233.136.8) by locus.apache.org with SMTP; 11 Jul 2000 03:33:08 -0000 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id XAA12048 for ; Mon, 10 Jul 2000 23:33:38 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id XAA23559 for ; Mon, 10 Jul 2000 23:32:41 -0400 (EDT) Subject: Re: [spinnaker] Announce To: general@xml.apache.org X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999 Message-ID: From: "Scott Boag/CAM/Lotus" Date: Mon, 10 Jul 2000 23:25:51 -0400 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_06082000 |June 8, 2000) at 07/10/2000 11:35:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii > I disagree. I don't think that keeping sync across C++ and Java is > reasonable given that two very different coding strategies really should be > used to make each appropriate for it's environment. A big +1 on this. Java is a very different language from C++, and you need different strategies. -scott James Duncan Davidson To: Subject: Re: [spinnaker] Announce 07/10/2000 05:34 PM Please respond to general on 7/10/00 2:05 PM, Joe Polastre at polastre@jtcsv.com wrote: > I'd also like to see this be coordinated with the xerces-c developers since > the source base for xerces-c is based on the original xerces-j. it would be > nice to keep the two parsers in sync so that changes to one parser and > relatively easy to implement in the other. plus, i haven't seen anyone > comment on the implications towards the c++ parser by starting a new branch > that could possibly become the new xerces-j. [us C++ developers are real > people too!] I disagree. I don't think that keeping sync across C++ and Java is reasonable given that two very different coding strategies really should be used to make each appropriate for it's environment. I think that the feature sets and goals should be similar -- SAX, DOM... But the implementation should be different. .duncan --------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: general-unsubscribe@xml.apache.org For additional commands, e-mail: general-help@xml.apache.org