[jdom-interest] DOMOutputter and other thoughts

[Brett McLaughlin]

Kevin Regan wrote:
> 
> 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,

Because that's what the adapaters are for - if you require it to take a
DOMImplementation, you make users write vendor specific code. Period. We
don't do that, or we need things like JAXP, which we currently don't.
You can add methods to DOMAdapter if you need them, but once you create
the Document (from DOMAdapter - createDocument()), you can use
createXXX.

> 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):

The DocumentType is an aberation, and for things like that you need to
add to DOMAdapter - createDocumentType, which uses Xerces-specific code,
ORacle-specific code, etc., to return a DocumentType implementation. No
JDOM input/output/core code will ever need the user to do anything but
type in String classes for things like org.apache.xerces. And we don't
want them to need to know anything other than "I use Xerces." More than
that, and I -1 it, because we don't need it.

> 
> ------------------------------------------------------------------
> 
> 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
> Declaration, therefore
>      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

Or do new org.apache.xerces.dom.DocumentTypeImpl, which is the point of
DOMAdapter.

> 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.
> 

No way - the user doesn't understand that. We make life easy, by
allowing them to hand you a JDOM Document and get a DOM Document back.
I'm really firm on this.

> By the way, I was not sure what you meant by the distinction
> between a DOM tree and DOM document.  Can you clarify what
> you meant?

DOM tree is an abstract concept. DOM Document is a DOM Node (concrete
class).

-Brett

> 
> --Kevin
> 
> 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
> > parser
> > > > implementation. Nobody is familiar with DOMImplementation anyway...
> > > >
> > >
> > > BUT .. if the eventual goal is to create a JDOM specific parser AND
> > JDOM
> > > 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
> > started
> > > thinking about it and had come to the same conclusion as Kevin.
> > Certainly,
> > > using the adapters would be easier.  For a version 1 release you could
> > do
> > > something as simple as using XMLOutputter to create a XML string and
> > then
> > > use an adapter to produce the DOM tree.  I'm not sure how much slower
> > that
> >
> > 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
> > to
> > > 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
> > hours...
> >
> > -Brett
> >
> > >
> > > > > 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
> > us
> > > > otherwise.)
> > >
> > > I agree.  One of the great things about JDOM is that each class is so
> > small.
> > > I would rather have this separated into a separate set of DOM
> > implementation
> > > classes.
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > >
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
> > rhost.com
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
> > rhost.com
> >