xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott_B...@lotus.com
Subject Re: Potential Xerces regression (bug# 933)
Date Tue, 13 Mar 2001 23:38:19 GMT

> BTW, as I understand it, methods are no longer marked with "@deprecated"
> b/c this causes compiler warnings.

Hmm... I thought that was the point.  I don't understand "non-preferred",
if it means the method or class is not going away.  Either an API is fully
supported, or not, in which case it should go away, i.e. be deprecated.
"non-preferred" just means that I may feel a tinge of guilt when I use it
if I happen to read the javadoc, nothing more.

Anyhow, note that the javax.xml.* code in Xerces is a bit out of synch with
the javax.xml.* code in Xalan.  Hopefully this is just javadoc, but it
should be fixed.

> I'm not sure I understand the need for this.  Since JAXP is limited to
> XML parsing, all implementations will have some class that will
> implement the DOM Document interface, so the
> DocumentBuilder#newDocument() method can just return a new instance of
> that class.  Something else to be discussed on the JSR63 list, perhaps?

As the DOM spec sits, DOM Document implementations should be able to be
written with the assumption that they will never ever be without a root
element... i.e. a joe.blow.DocumentImpl#DocumentImpl() constructor may not
exist.

-scott




                                                                                         
                          
                    Edwin Goei                                                           
                          
                    <Edwin.Goei@en        To:     general@xml.apache.org              
                             
                    g.sun.com>            cc:     xerces-j-dev@xml.apache.org, Joe Kesselman
                       
                                          <Joseph_Kesselman@lotus.com>, (bcc: Scott
Boag/CAM/Lotus)                 
                    03/13/01 07:06        Subject:     Re: Potential Xerces regression (bug#
933)                   
                    PM                                                                   
                          
                    Please respond                                                       
                          
                    to general                                                           
                          
                                                                                         
                          
                                                                                         
                          




Scott_Boag@lotus.com wrote:
>
> > JAXP 1.1, which is based on DOM Level 2, exposes a new method to create
> > a DOM Document object to conform to DOM Level 2.  This is the preferred
> > method to create a DOM Level 2 tree:
> >
> > DocumentBuilderFactory dbf = new DocumentBuilderFactory();
> > dbf.setNamespaceAware(true);  // needed b/c default value is false
> > DocumentBuilder db = dbf.newDocumentBuilder();
> > DOMImplementation di = db.getDOMImplementation();  // W3C DOM Impl
> > DocumentType dt = di.createDocumentType("pref:root", pubID, sysId);
> > Document doc = createDocument("http://someuri", "pref:root", dt);
>
> Edwin, this will not work for XSLT processing with JAXP 1.1.  People want
> to create a Document node and have it populated by the XSLT processor.
In
> order to support this we will have to change
> javax.xml.transform.dom.DOMResult to hold a DOMImplementation that can be
> passed in, so that Xalan can create the document node when an element
node
> is created (besides the change in JAXP, this is a fair amount of work in
> Xalan, because this non-node will have to be passed through the entire
> processing flow).

OK well, then using DocumentBuilder.newDocument() will still work.  Here
is the JAXP development timeline: first there was DOM (Level 1) which
did not define a way to create a DOM Document, then JAXP 1.0 appeared
which filled this need by adding DocumentBuilder.newDocument(), then
came DOM Level 2, which added
DOMImplementation.createDocument(rootElement,...), then came JAXP 1.1.
So the new DOM Level 2 createDocument(rootElement...) creation mechanism
is fundamentally different from JAXP 1.0 b/c it specifies the XML root
element as an argument.  So in JAXP 1.1,
DocumentBuilder.getDOMImplementation() was added to allow apps to create
documents the DOM Level 2 way.

> God, I wish this had been caught 3 months ago.  Perhaps
> we can make that change for JAXP 1.2 or 1.1.1.  But, in any case, the
> Javadoc does not seem to deprecate DocumentBuilderImpl#newDocument() that
I
> can see, so there's nothing to say it's "not preferred".  This is a
> flat-out mismatch with DOM2.

Maybe using DocumentBuilder.newDocument() should not be marked
"non-preferred" (deprecated) b/c it adds another way to create a DOM
Document object, which may be useful for apps like Xalan that want to
create a generic DOM Document without a root element.  I am not sure if
it conflicts with DOM b/c I have not had time to keep up to date with
future DOM plans.  Perhaps Joe Kesselman can comment?

BTW, as I understand it, methods are no longer marked with "@deprecated"
b/c this causes compiler warnings.  This issue may need to be cc-ed to
the JSR-63 list (which is where JAXP 1.1 issues are discussed).

>
> I think that the near term solution to this is that it be documented that
> DocumentBuilder#newDocument() can throw a not supported exception for
some
> DOM implementations, and precisely document that the Document returned is
> in a temporarily invalid state that does not match any state recognized
by
> the DOM.

I'm not sure I understand the need for this.  Since JAXP is limited to
XML parsing, all implementations will have some class that will
implement the DOM Document interface, so the
DocumentBuilder#newDocument() method can just return a new instance of
that class.  Something else to be discussed on the JSR63 list, perhaps?

-Edwin

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org






---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message