You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by "K. Ari Krupnikov" <ar...@iln.net> on 2001/03/02 21:19:04 UTC
Using DOMParser to produce a non-Xerces Document
Hi,
What is the recommended way to use Xerces parser to build a DOM tree in
a different implementation?
I subclassed org.apache.xerces.parsers.DOMParser such that
DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
fDocument is set to an empty Document from my implementation. [1]
Is there a better way?
[1]
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/alpha/java/src/il/co/iter/dbdom/parsers/DBDOMParser.java?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=dbdom
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
Re: docType in case of non-default document-class-name
Posted by se...@cern.ch.
I actually found the reason of this behavior : when you redefine
http://apache.org/xml/properties/dom/document-class-name, you lose everything
implemented in the DocumentImpl class (which is pretty normal) but also half of what is
implemented inside the DOMParser since it's directly and explicitely using the
DocumentImpl class.
What I would like is to keep this code, at least in case you're just subclassing
DocumentImpl to change its behavior. This could be done by applying the following
little patch to the parser :
Index: DOMParser.java
===================================================================
RCS file:
/home/cvspublic/xml-xerces/java/src/org/apache/xerces/parsers/DOMParser.java,v
retrieving revision 1.40
diff -5 -r1.40 DOMParser.java
911a912
> boolean isInstanceOfDocumentImpl =
Class.forName(DEFAULT_DOCUMENT_CLASS_NAME).isAssignableFrom(Class.forName(fDocumentClassName));
937a939,941
>
if (isInstanceOfDocumentImpl) {
>
fDocumentImpl = (DocumentImpl) fDocument;
>
}
Is it reasonnable ?
If yes, could someone commit it ?
Sebastien
sebastien.ponce@cern.ch wrote:
> I'm having some problems with the
> http://apache.org/xml/properties/dom/document-class-name property of the DOM parser.
>
> Actually, when I set it to my own document implementation, which is an empty wrapper
> around the default one, the documents do not have a document type. The parsing seems
> however to be done correctly. Is it a bug in the default DocumentImpl implementation
> ?
>
> Sebastien
docType in case of non-default document-class-name
Posted by se...@cern.ch.
I'm having some problems with the
http://apache.org/xml/properties/dom/document-class-name property of the DOM parser.
Actually, when I set it to my own document implementation, which is an empty wrapper
around the default one, the documents do not have a document type. The parsing seems
however to be done correctly. Is it a bug in the default DocumentImpl implementation
?
Sebastien
Here is the code I use :
import org.apache.xerces.dom.*;
import org.apache.xerces.parsers.*;
public class Test2 {
public static void main (String[] args) {
DOMParser parser = new DOMParser();
try {
parser.setProperty("http://apache.org/xml/properties/dom/document-class-name",
"MyDocumentImpl");
} catch (org.xml.sax.SAXNotSupportedException e) {
} catch (org.xml.sax.SAXNotRecognizedException e) {
}
try {
parser.parse("File:///home/sponce/mycmt/Det/XmlEditor/v3d1/src/Test2.xml");
} catch (java.io.IOException e) {
} catch (org.xml.sax.SAXException e) {
}
Document document = parser.getDocument();
DocumentType documentType = document.getDoctype();
System.out.println(documentType);
}
}
The MyDocumentImpl class :
import org.apache.xerces.dom.*;
import org.w3c.dom.*;
public class MyDocumentImpl extends DocumentImpl {
public MyDocumentImpl() {
super();
}
public MyDocumentImpl(boolean grammarAccess) {
super(grammarAccess);
}
public MyDocumentImpl(DocumentType doctype) {
super(doctype);
}
public MyDocumentImpl(DocumentType doctype, boolean grammarAccess) {
super(doctype, grammarAccess);
}
}
And the xml file I use for testing :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DDDB SYSTEM "DTD/structure.dtd">
<DDDB>
</DDDB>
HTMLDocumentImpl, HTMLCollectionImpl, getAnchors()
Posted by gordy perkins <go...@yahoo.com>.
I'm trying to parse simple HTML pages and using the
HTMLDocumentImpl. Has anyone used these classes
successfully?
First, HTMLCollection was not public, so I made it so.
Second, in HTMLDocumentImpl, the methods for
getForms(), getAnchors(), getApplets(), getLinks()
returned HTMLCollection, not HTMLCollectionImpl. I
changed them as well.
Now in compiling HTMLDocumentImpl, I get:
..cannot implement getAnchors in
org.w3.dom.html.HTMLDocument attempting to use
incompatible return type.
found: org.apache.html.dom.HTMLCollectionImpl
required: org.w3.dom.html.HTMLCollection
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
"K. Ari Krupnikov" wrote:
> xerces_j_2 DOMParser extends AbstractDOMParser; MAIN, XMLParser.
This was a mistake. Some experimental parser configuration work
was added to the HEAD accidentally; it should have been added
to the "xerces_j_2" branch. I think that Arnaud will be fixing
this shortly. Right, Arnaud? ;)
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Arnaud Le Hors wrote:
>
> "K. Ari Krupnikov" wrote:
> >
> > Ehh? I'm afraid I'm not on the cvs-commit list :=)
> >
> > Would it be reasonable to use the production (1.3) version, or has there
> > been significant work done?
>
> You can check out code anonymously. See http://xml.apache.org/cvs.html
That part I figured out :=) I was hoping you'd help me make sense of the
branches, tags, and what is and isn't stable.
xerces_j_2 DOMParser extends AbstractDOMParser; MAIN, XMLParser.
If I patch xerces_j_2, I need to patch the superclass, not DOMParser
itself. Is _it_ stable?
Is MAIN stable? Both branches seem to have had work done on them
recently -- is there a stable tag I can check out? Or is 1.3 considered
close enough? 1.3 is what I'm using.
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by Arnaud Le Hors <le...@us.ibm.com>.
"K. Ari Krupnikov" wrote:
>
> Ehh? I'm afraid I'm not on the cvs-commit list :=)
>
> Would it be reasonable to use the production (1.3) version, or has there
> been significant work done?
You can check out code anonymously. See http://xml.apache.org/cvs.html
--
Arnaud Le Hors - IBM Cupertino, XML Strategy Group
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Arnaud Le Hors wrote:
>
> "K. Ari Krupnikov" wrote:
> >
> > A stupid question - which cvs tag should I patch against?
>
> Definitely not stupid! I'd say it's your choice at this point. Which
> version of Xerces are you using? If it's Xerces1 just work off the
> trunc. If it's Xerces2 it's on the branch Xerces_j_2. Hmm... As I say
> this I realize that this part of the code in Xerces2 is under work...
> So, it might be easier to just do it on Xerces1 which is more stable.
> We'll manage to merge the changes back to Xerces2 later.
Ehh? I'm afraid I'm not on the cvs-commit list :=)
Would it be reasonable to use the production (1.3) version, or has there
been significant work done?
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by Arnaud Le Hors <le...@us.ibm.com>.
"K. Ari Krupnikov" wrote:
>
> A stupid question - which cvs tag should I patch against?
Definitely not stupid! I'd say it's your choice at this point. Which
version of Xerces are you using? If it's Xerces1 just work off the
trunc. If it's Xerces2 it's on the branch Xerces_j_2. Hmm... As I say
this I realize that this part of the code in Xerces2 is under work...
So, it might be easier to just do it on Xerces1 which is more stable.
We'll manage to merge the changes back to Xerces2 later.
--
Arnaud Le Hors - IBM Cupertino, XML Strategy Group
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the second is better because people create their
> parsers from JAXP and have no way of passing arguments
> to the constructor. Unfortunately, though, JAXP doesn't
> have an extensive feature/property mechanism for DOM as
> it does for SAX -- so we're back to creating the parser
> object directly, anyway... <sigh/>
>
> > http://apache.org/xml/properties/dom/document-class-name doesn't need to
> > be set explicitly - it can be established at runtime, and probably isn't
> > needed at all, since you can call a standard factory method instead of
> > newInstance()
>
> For backward compatibility, though, I wouldn't remove this
> property. Perhaps as we move to Xerces2, we can remove it
> there and rely on the DOMImplementation object instead.
>
> > I can patch DOMParser if there is interest in these solutions. It appers
> > that changes would be limited to org.apache.xerces.parsers.DOMParser
>
> Patches for new features as well as bug fixes are always
> accepted. :)
A stupid question - which cvs tag should I patch against?
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@cogsci.ed.ac.uk>.
Andy Clark wrote:
>
> Xerces2 doesn't have a StringPool, so String objects are passed
> to the native interfaces. Both Xerces 1.x and Xerces2 have
> internal interfaces but at least we're trying to "standardize"
> the interfaces in Xerces2 (this is what we call XNI).
>
> In both versions, you can directly extend the DOMParser class
> and override the appropriate method to get the information
> that you need. In Xerces 1.x, you'll have to turn the ints
> into String objects by calling the StringPool:
>
> String s = fStringPool.toString(i);
>
> But in Xerces2, you'll just get the String object directly.
Is there a reason both versions of DOMParser, as well as
org.apache.xerces.xni.XMLDTDHandler don't use
org.xml.sax.ext.DeclHandler? The methods seem to have the same masks...
The alternative would be to go with a SAX parser, but then we'd have to
rewrite all Document.createXxx() calls, which looks like a waste.
Ari.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
Xerces2 doesn't have a StringPool, so String objects are passed
to the native interfaces. Both Xerces 1.x and Xerces2 have
internal interfaces but at least we're trying to "standardize"
the interfaces in Xerces2 (this is what we call XNI).
In both versions, you can directly extend the DOMParser class
and override the appropriate method to get the information
that you need. In Xerces 1.x, you'll have to turn the ints
into String objects by calling the StringPool:
String s = fStringPool.toString(i);
But in Xerces2, you'll just get the String object directly.
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@cogsci.ed.ac.uk>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the second is better because people create their
> parsers from JAXP and have no way of passing arguments
> to the constructor. Unfortunately, though, JAXP doesn't
> have an extensive feature/property mechanism for DOM as
> it does for SAX -- so we're back to creating the parser
> object directly, anyway... <sigh/>
>
> > I can patch DOMParser if there is interest in these solutions. It appers
> > that changes would be limited to org.apache.xerces.parsers.DOMParser
>
> Patches for new features as well as bug fixes are always
> accepted. :)
Hi, I'm back again after a month of moving and getting connected.
I'm still trying to change DOMParser to work with my DBDOM database.
Here's a question about DTD and in particular, entity handling.
I need to intercept entity declarations in the DTD to build my own
DocumentType.Entities. Unlike SAXParser, DOMParser doesn't use
http://xml.org/sax/properties/declaration-handler. Xerces 1's DOMParser
has internalEntityDecl(int entityNameIndex, int entityValueIndex) which
cannot be used without stringpools (am I correct here? are stringpools
going away in Xerces 2?)
In Xerces 2, AbstractXMLDocumentParser has
internalEntityDecl(java.lang.String name, XMLString text) which looks
like org.xml.sax.ext.DeclHandler.internalEntityDecl(java.lang.String
name, java.lang.String value), except it's impossible to override with a
custom DeclHandler (or is it?)
So, short of using a SAX parser instead of a DOM one, is there a way to
override the default entity declaration handling in Xerces?
Ari.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the second is better because people create their
> parsers from JAXP and have no way of passing arguments
> to the constructor. Unfortunately, though, JAXP doesn't
> have an extensive feature/property mechanism for DOM as
> it does for SAX -- so we're back to creating the parser
> object directly, anyway... <sigh/>
Directly as in with no arguments from the user, not as in newInstance()!
That makes all the difference in the world :=)
> > I can patch DOMParser if there is interest in these solutions. It appers
> > that changes would be limited to org.apache.xerces.parsers.DOMParser
>
> Patches for new features as well as bug fixes are always
> accepted. :)
I'll see what I can do!
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
"K. Ari Krupnikov" wrote:
> 1) add a constructor that takes a DOMImplementation argument and
> overload init() and reset(). In this case,
I like this solution. Either a constructor or having a
property for the DOMImplementation object works for me.
Perhaps the second is better because people create their
parsers from JAXP and have no way of passing arguments
to the constructor. Unfortunately, though, JAXP doesn't
have an extensive feature/property mechanism for DOM as
it does for SAX -- so we're back to creating the parser
object directly, anyway... <sigh/>
> http://apache.org/xml/properties/dom/document-class-name doesn't need to
> be set explicitly - it can be established at runtime, and probably isn't
> needed at all, since you can call a standard factory method instead of
> newInstance()
For backward compatibility, though, I wouldn't remove this
property. Perhaps as we move to Xerces2, we can remove it
there and rely on the DOMImplementation object instead.
> I can patch DOMParser if there is interest in these solutions. It appers
> that changes would be limited to org.apache.xerces.parsers.DOMParser
Patches for new features as well as bug fixes are always
accepted. :)
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > > Why is it not possible? Is this your own document impl or
> > > something else?
> >
> > It's my (and a few other people's) own.
> > http://sourceforge.net/projects/dbdom
>
> Okay, now I'm getting the picture...
>
> If you have any ideas as to how to make your scenario (and
> similar ones) feasible in the parser, that would be great.
> Perhaps just setting the document factory impl instead of
> the document impl?
1) add a constructor that takes a DOMImplementation argument and
overload init() and reset(). In this case,
http://apache.org/xml/properties/dom/document-class-name doesn't need to
be set explicitly - it can be established at runtime, and probably isn't
needed at all, since you can call a standard factory method instead of
newInstance()
2) add a constructor that takes a Document argument and overload init()
and reset(). This method would make sense in applications (such as
DBDOM) where Document can have extra information - in our case, a unique
name - and so cannot be created with a standard DOM method. The Document
would be expected to have no child nodes. Although I don't think this
should be enforced - it might provide a convenient way to incrementally
build documents. Again, no need to use newInstance( and hence no need
for a string class name.
These two are obviously not mutually exclusive.
If DOMImplementation or Document is null, use default
xerces.dom.DocumentImpl
3) Catch the unchecked ClassCastException, or, better yet, check the
class of the Attribute before casting it in startElement() (line 1078)
in DOMParser, depending on which scenario (AttrImpl or other Attr) you
think is the more likely -
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=832
I can patch DOMParser if there is interest in these solutions. It appers
that changes would be limited to org.apache.xerces.parsers.DOMParser
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
"K. Ari Krupnikov" wrote:
> > Why is it not possible? Is this your own document impl or
> > something else?
>
> It's my (and a few other people's) own.
> http://sourceforge.net/projects/dbdom
Okay, now I'm getting the picture...
If you have any ideas as to how to make your scenario (and
similar ones) feasible in the parser, that would be great.
Perhaps just setting the document factory impl instead of
the document impl?
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > > You don't need to subclass the parser itself; you only need to
> > > set the appropriate property on the parser to set the new DOM
> > > implementation by using the fully qualified class name. For
> > > example:
> > > [...]
> >
> > I'm afraid that's not possible. My Document doesn't have a public
> > no-argument constructor. It can only be instantiated using a factory
>
> Why is it not possible? Is this your own document impl or
> something else?
It's my (and a few other people's) own.
http://sourceforge.net/projects/dbdom
> If it's you own, why can't you create a
> document without creating it from the DOMImplementation
> factory?
Because my Java DOM is a facade to a database. A Document cannot be
created, much less populated, outside a database. So at the very least,
a Document constructor needs an open JDBC connection. It doesn't have to
be produced by a factory, but it can't have a no-args constructor,
either.
> I think that this feature was added before DOM L2 Rec so
> we don't have a way of setting the document factory and
> using that for constructing a DOM tree. Also, say we *did*
> have a way to set this, then what would we pass in as the
> doctype parameter? Null? If so, how do we set the document
> type later when we see one in the document? If not, then
> what if the document doesn't contain a DOCTYPE line? Some
> users would argue that a DOM tree should not have a
> DocumentType node if there is no DOCTYPE line in the
> document instance. And I think that I agree.
I'm not sure I follow you here. The Rec [1] specifies createDocumentType
in addition to createDocument. If "<!DOCTYPE..." is found before the
first element, use its information to create a DocumentType; if not, use
null in createDocument. Is the problem holding comments and PIs that
might come before the doctype?
In any case, regardless of the DocType, init() can be overloaded to
produce something like init(Document) where Document is expected to be
empty.
As I mentioned, what we did was subclass DOMParser with a public
constructor that takes an empty Document, which is essentially the same,
except the parser is non-reusable.
[1] http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-102161490
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
"K. Ari Krupnikov" wrote:
> > You don't need to subclass the parser itself; you only need to
> > set the appropriate property on the parser to set the new DOM
> > implementation by using the fully qualified class name. For
> > example:
> > [...]
>
> I'm afraid that's not possible. My Document doesn't have a public
> no-argument constructor. It can only be instantiated using a factory
Why is it not possible? Is this your own document impl or
something else? If it's you own, why can't you create a
document without creating it from the DOMImplementation
factory?
I think that this feature was added before DOM L2 Rec so
we don't have a way of setting the document factory and
using that for constructing a DOM tree. Also, say we *did*
have a way to set this, then what would we pass in as the
doctype parameter? Null? If so, how do we set the document
type later when we see one in the document? If not, then
what if the document doesn't contain a DOCTYPE line? Some
users would argue that a DOM tree should not have a
DocumentType node if there is no DOCTYPE line in the
document instance. And I think that I agree.
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
Re: Using DOMParser to produce a non-Xerces Document
Posted by "K. Ari Krupnikov" <ar...@iln.net>.
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > What is the recommended way to use Xerces parser to build a DOM tree in
> > a different implementation?
> >
> > I subclassed org.apache.xerces.parsers.DOMParser such that
> > DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
> > fDocument is set to an empty Document from my implementation. [1]
> >
> > Is there a better way?
>
> You don't need to subclass the parser itself; you only need to
> set the appropriate property on the parser to set the new DOM
> implementation by using the fully qualified class name. For
> example:
>
>
> domParser.setProperty("http://apache.org/xml/properties/dom/document-class-name",
> "andyc.MyDocumentImpl");
>
I'm afraid that's not possible. My Document doesn't have a public
no-argument constructor. It can only be instantiated using a factory
method in DOMImplementation, because it cannot exist outside of an
Implementation instance, same as regular Node cannot exist outside of
the context of a Document.
Also, I ran into problems with org.apache.xerces.parsers.DOMParser when
it attempts to cast Attr into AttrImpl regardless of
http://apache.org/xml/properties/dom/document-class-name. I reported
that as a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=832
--
K. Ari Krupnikov
DBDOM - bridging XML and relational databases
http://www.iter.co.il
Re: Using DOMParser to produce a non-Xerces Document
Posted by Andy Clark <an...@apache.org>.
"K. Ari Krupnikov" wrote:
> What is the recommended way to use Xerces parser to build a DOM tree in
> a different implementation?
>
> I subclassed org.apache.xerces.parsers.DOMParser such that
> DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
> fDocument is set to an empty Document from my implementation. [1]
>
> Is there a better way?
You don't need to subclass the parser itself; you only need to
set the appropriate property on the parser to set the new DOM
implementation by using the fully qualified class name. For
example:
domParser.setProperty("http://apache.org/xml/properties/dom/document-class-name",
"andyc.MyDocumentImpl");
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org