[jdom-interest] DOMOutputter and other thoughts

[Kevin Regan]

I am still not following you.  The DOMOutputter has this method:

void DOMOutputter.output(Document document, org.w3c.dom.Document
domTree)

the Xerces adaptor has:

org.w3c.dom.Document XercesDOMAdaptor.createDocument();

I don't see the connection.  The user wants to call
DOMOutputter.output(), but the above interface does
not cut it.  You say to "use an adaptor", but I don't
see how that is possible.

In DOM Level 2, the DocumentType and DOMImplementation are
in the standard DOM interface.  I'm not sure why you consider
these aberations. They aren't Xerces specific, the are common
to all DOM Level 2 implementation, correct?

Maybe to make things clear for everyone, you can write a few
lines of code, to show exactly what you think the client will
be doing to create a DOM tree from a JDOM tree.

--Kevin


On Mon, 12 Jun 2000, Brett McLaughlin wrote:

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