Return-Path: Delivered-To: apmail-xml-xalan-dev-archive@xml.apache.org Received: (qmail 60334 invoked by uid 500); 7 Mar 2003 02:17:06 -0000 Mailing-List: contact xalan-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: xalan-dev@xml.apache.org Delivered-To: mailing list xalan-dev@xml.apache.org Received: (qmail 60320 invoked from network); 7 Mar 2003 02:17:06 -0000 Received: from mail11.speakeasy.net (HELO mail.speakeasy.net) (216.254.0.211) by daedalus.apache.org with SMTP; 7 Mar 2003 02:17:06 -0000 Received: (qmail 5363 invoked from network); 7 Mar 2003 02:17:27 -0000 Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Mar 2003 02:17:27 -0000 Mime-Version: 1.0 X-Sender: elharo@mail.ibiblio.org Message-Id: In-Reply-To: <200303061804.h26I45u28622@ha2sca-mail1.SFBay.Sun.COM> References: <200303061804.h26I45u28622@ha2sca-mail1.SFBay.Sun.COM> Date: Thu, 6 Mar 2003 21:14:58 -0500 To: xalan-dev@xml.apache.org From: Elliotte Rusty Harold Subject: Re: JAXP.next JSR Proposal Cc: jsr-206-comments@JCP.ORG, Ramesh Mandava Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 10:04 AM -0800 3/6/03, Ramesh Mandava wrote: > I agree with the problem users are facing to override the parser/transformer >that is part of JDK. To avoid this problem and to allow users to override the >parser/transformer with new parser/transformer ( for eg. from Apache >) , Sun is >planning to rename the parser/transformer classes that would go into next JDK >release. With this change users can override the parser/transformer just by >putting the latest version in CLASSPATH ( As the names of classes >are different This is an improvement. If this had been implemented in 1.4 it would mean, for instance, that you could easily use the current Xalan rather than the older, buggier 2.2d-10 that's bundled with the JDK. It's a good idea. However, as Joseph Kesselman already pointed out this does not yet address the concerns about evolving SAX and DOM out of sync with the JDK. For instance, it would not allow Xerces to support a theoretical SAX 2.1 if JAXP didn't. To fix this, you'd need to bundle the SAX/DOM classes in some place that's loaded after the user's classpath and jre/lib/ext rather than before, and you'd need to lighten up on the compatibility tests to at least allow additional classes and methods. -- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Processing XML with Java (Addison-Wesley, 2002) | | http://www.cafeconleche.org/books/xmljava | | http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.cafeconleche.org/ | +----------------------------------+---------------------------------+