[jdom-interest] DOMOutputter and other thoughts
kevinr at valicert.com
Mon Jun 12 12:17:28 PDT 2000
Hmm, I didn't say it would be difficult, I just had some
questions about the interface... :-)
Basically, we just need to reverse the code in the DOMBuilder.
However, I'm still not sure why the DOMOutputter does not
need a DOMImplementation to build the DOM tree. Furthermore,
I don't see how the adaptor classes can implement this.
Looking at DOM Level 2, there does not seem to be
a way to modify the DocumentType after the Document
is created (this is specifically documented as such):
public DocumentType Document.getDoctype()
The Document Type Declaration (see DocumentType ) associated with
this document. For
HTML documents as well as XML documents without a document type
declaration this returns
null . The DOM Level 2 does not support editing the Document Type
docType cannot be altered in any way, including through the use of
methods, such as
insertNode or removeNode , inherited from Node .
Therefore, in order to copy the JDOM to the DOM,
you need to first create the DocumentType with a call
to DOMImplementation.createDocumentType() and
and then use the DOMImplementation.createDocument call to
actually create the document. In addition, the DOMOutputter class only
takes a DOM Document. There is no way to change this reference to
something else and no way to set any DocumentType information.
I think the best way to go about this is to have DOMOutputter
take a DOMImplementation. Then, the user can create a DOM
tree with any implementation that he likes.
By the way, I was not sure what you meant by the distinction
between a DOM tree and DOM document. Can you clarify what
On Mon, 12 Jun 2000, Brett McLaughlin wrote:
> philip.nelson at omniresources.com wrote:
> > I now have a desire/need for this as well so here are my 2 cents
> > > > I've been taking a look at the DOMOutputter class
> > > > and it seems that this will need to take a
> > > > org.w3c.dom.DOMImplementation rather than a
> > >
> > > Nope - use the JDOM adapters to get a Document from a specific
> > > implementation. Nobody is familiar with DOMImplementation anyway...
> > >
> > BUT .. if the eventual goal is to create a JDOM specific parser AND
> > will support DOM, isn't a JDOM DOMDocument implementation the best way
> to do
> JDOM does not and will never /support/ DOM. It will talk to DOM and from
> DOM, nothing else.
> > it? Before I realized that someone else had started this I had
> > thinking about it and had come to the same conclusion as Kevin.
> > using the adapters would be easier. For a version 1 release you could
> > something as simple as using XMLOutputter to create a XML string and
> > use an adapter to produce the DOM tree. I'm not sure how much slower
> No. You get an empty Document object from the DOM Adapaters, and then
> populate that Document with Nodes, generated from the JDOM objects.
> > would be than manually creating the DOM tree but the API wouldn't have
> > change to implement it with the manual DOM building step so there
> isn't a
> > huge downside.
> The mapping from JDOM to DOM is simple - I would do it myself, but I
> have no time - I'm not sure if Kevin thinks about it differently, as he
> seems to think it is harder than it is ;-) If I get time, I'll do it on
> the plane Friday - I really don't think it should take more than 3
> > > > One other thought, just a pie-in-the-sky idea, was to have the
> > > > JDOM classes implement the DOM interface so that they could be
> > > > used directly by DOM applications:
> > > >
> > > Nope. Already went down that road, and vetoed it heavily. Bad news
> > > (trust us, JDOM alpha 1 was like that, and James Davidson convinced
> > > otherwise.)
> > I agree. One of the great things about JDOM is that each class is so
> > I would rather have this separated into a separate set of DOM
> > classes.
> > _______________________________________________
> > To control your jdom-interest membership:
> To control your jdom-interest membership:
More information about the jdom-interest