From Edwin.Goei@eng.sun.com Wed Oct 18 18:36:31 2000 Return-Path: Mailing-List: contact general-help@xml.apache.org; run by ezmlm Delivered-To: mailing list general@xml.apache.org Received: (qmail 14230 invoked from network); 18 Oct 2000 18:36:31 -0000 Received: from mercury.sun.com (192.9.25.1) by locus.apache.org with SMTP; 18 Oct 2000 18:36:31 -0000 Received: from shorter.eng.sun.com ([129.144.251.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19385 for ; Wed, 18 Oct 2000 11:36:30 -0700 (PDT) Received: from eng.sun.com (d-ucup02-124-57 [129.144.124.57]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA29929 for ; Wed, 18 Oct 2000 11:36:30 -0700 (PDT) Message-ID: <39EDEDC0.185925FC@eng.sun.com> Date: Wed, 18 Oct 2000 11:36:48 -0700 From: Edwin Goei X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: general@xml.apache.org Subject: Re: Question about document type nodes and JAXP References: <011a01c0392a$7da440a0$6a1010ac@rosetta.zon> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Sean Kelly wrote: > > > Really? That's what I'm doing, but I thought it would just be a temporary > > hack. :-( > > I wish ... but as Arnaud said, there's no factory method in the DOM spec to > get useful objects like this. > > In my own code, I've wrapped all non-DOM, non-SAX methods into a class with > a bunch of static methods wrapping the underlying XML implementation (plus > some API sugaring here and there) in order to minimize the impact of changes > to versions of Xerces, or changes to other XML implementations. The two classes in the javax.xml.parsers package of JAXP attempt to bridge the gap between what the DOM API currently provides and what apps need to use the DOM API. For example, DOM (as of Level 2) does not provide a way to load in an XML file to create a DOM tree, the javax.xml.parsers package provides this. -Edwin