[jdom-interest] DOMOutputter and other thoughts

[Brett McLaughlin]

philip.nelson at omniresources.com wrote:
> 
> > > > Nope - use the JDOM adapters to get a Document from a
> > specific parser
> > > > implementation. Nobody is familiar with DOMImplementation
> > anyway...
> > > >
> 
> OK but....
> > >
> > > 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.
> >
> 
> At the risk of sounding dull witted, I still see a conflict with this
> statement.  I really do remember earlier messages talking about a JDOM
> specific parser.  The reason for the parser would be to allow deferred

Yeah, that's something we do want in the future.

> parsing of parts of the document, a lighter footprint, no dependence on
> Xerces or other parsers etc..  Since XSLT and possibly other tools do
> require a DOM Document, the conflict I see is that in order to use JDOM with

Actually (and I'm speaking a little out of turn, as this is ahead of
us), there are a couple of things that may make that unneccessary. For
instance, one guy submitted a patch to transform, via XSLT, a JDOM
Document, and return the result as a JDOM Document. It uses Xalan - now
while this currently means DOM is used, a better Xalan implementation,
something they are working on, might not need DOM. So we only need what
the "best-of-breed" product uses.  Additionally, as we get revved up on
XPath in JDOM 1.1, there are even more optimizations that we can make,
as we will have XPath support. So I do believe it is possible at some
point to remove that dependence on DOM, at least to a large degree.

> DOM consuming tools, you reintroduce the need for an external parser
> package.  So even though I may have the whole document already loaded
> without the need for an external parser, I have to build a DOM document with
> an adapter and external parser, load an XSLT processor and then process.

Today, unfortunately, yes - but I know Xalan 1.1 is moving to some sort
of DOM subset, which will help - and it only gets better from there ;-) 
It is certainly possible for someone like Scott at Xalan to say "Hey,
JDOM is great, and has XPath now [in 1.1]; maybe we should use it as our
internal structure."

> 
> Wouldn't a JDOM based DOM adapter satisfy the API stated goal of not
> requiring the user to know anything about DOM?  Wouldn't it be more
> efficient for outputting a DOM?  Wouldn't if fit in easier when the JDOM
> specific parser was implemented?

I lost you a bit here - we have a DOM Adapter for JDOM, that does the
vendor-specific things in DOM (or some of them). As Kevin pointed out
yesterday, DocumentType creation is probably another one that could be
added. If we needed a DOMImplementation, then that might need to be
added. I don't think there's a need for mappings to things like Element,
Attribute, etc., though, because those can all be created in
vendor-neutral ways from the Document object, which of course is pulled
from the DOMAdapater. Or am I missing the point? (altogether possible
;-) )

> 
> All of these comments are irrelevant so far as the current discussion of a
> DOMOutputter that could work with current adapters, particularly if a
> different parser such as Spitfire satisfies the other parser goals that have
> been discussed so far.  I wish this discussion wasn't taking up more of your
> time when you only hoped to get the dang thing done without having to do it
> yourself.  I would give it try but it would not happen before your plane
> trip on Friday!

Yes. And I'll be the first to admit, publicly, that I got too frustrated
with Kevin - instead of taking a deep breath, I reacted. I'm onsite at
my job, which only happens every couple of months, so my time is
crammed. Still, I should have taken 30 minutes to write some more
skeleton code to help get where I was driving at across - also, in
talking to Jason last night, it seems that Kevin may have misinterpreted
something I said, and then I did the same back - in other words, we
began arguing at cross-purposes. That said, I agree I would love to see
DOMOuputter get done sooner rather than later, and I hope to get to work
on it some this weekend... but I'm more than happy to work with Kevin or
others to get it going... the following signatures, to clear the air,
are where I think we are:

public org.w3c.dom.Document output(org.jdom.Document);
public org.w3c.dom.Document output(org.jdom.Document, String
adapterClassName);

These would each return a newly created DOM Document.  THe bodies would
load either the default adapter (XercesDOMAdapter), or the one supplied
in adapterClassName, get a fresh DOM Docoument from that adapter
(createDocument), and then use that to create elements, attributes,
etc., for each JDOM similar construct. For things like DocumentType,
yup, we'd need to add new methods to the adapters.

Hope that makes some sense... it's early yet here on the West Coast ;-)

-Brett

> 
> Thanks for your efforts which will benefit me far more than my efforts will
> benefit you ;^)
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com