xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Goei <Edwin.G...@eng.sun.com>
Subject Re: Potential Xerces regression (bug# 933)
Date Wed, 14 Mar 2001 01:01:27 GMT
Scott_Boag@lotus.com wrote:
> > 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.

As I understand it, once a method is added to an API, it does not get
removed for application backward compatibility.  So another means to say
the same thing as "deprecated" without using the javadoc tag is used. 
In any case, I'm proposing to remove the "non-preferred" comment and
just point to an alternative way to create a DOM Document object via the
DOM Level 2 API.

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

Yes, this needs to be fixed as well as the resolution of some other
legal issues.

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

I see your point.  I'm not in charge of the spec, though, so you may
want to bring it up with the spec lead(s).  But perhaps this is just
splitting hairs, b/c one way around this problem is to only support
parsers that implement both JAXP 1.1 and DOM Level 2 APIs.  I don't see
it as much of a burden on a parser to implement the
DocumentBuilder#newDocument() method, and in fact the existing parsers
can easily implement it.


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

View raw message