You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xerces.apache.org by Pierpaolo Fumagalli <pi...@apache.org> on 2000/02/26 07:35:05 UTC
Public Release 1 comments and implementation
Hallo everyone... I've seen the new spec published today, and found a
very small inconsistence:
on page 21 the method SAXParser.getParser() is declared to throw a
SAXException, but later on, on page 23, that exception is not reflected
into the documentation. I believe the mistake resides on page 21,
because nothing should happen in the getParser() method but returning
the already instantiated and configured Parser() instance to the caller.
Also, I don't understand why the SAXParserFactory.newSAXParser() should
throw a SAXException, while DocumentBuilderFactory.newDocumentBuilder()
doesnt. Those methods already throw a ParserConfigurationException, so,
in my very humble opinion, the SAXException is redundant.
The last thing, I developed an implementation for the Apache XERCES
parser, both of the javax.xml.parser classes, and for their relative
implementation under the org.apache.xerces.jaxp package. If you could
give them a look and send me some feedback that would be greatly
appreciated (I implemented the javax.xml.parser classes also since
there's not an implementation currently available conforming to the
given spec, as far as I can see).
Thank you...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Public Release 1 comments and implementation
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> > Unfortunatly, the mistake is on page 23. In the javax.xml.parsers
> > documentation, we define the getParser method to throw the exception.
The
> > ommission on the method description is erroneous.
>
> Unfortunately :) Probably in version 1.1 it'll be removed. Anyway, as
> long as the two descriptions are coherent, it's good for me.
We'll see. But I will endeavor to make sure that the Final Release of the
spec is corrected here.
> I agree with you on that, in fact, expecially when considering SAX2
> properties and features, SAXExceptions come always into play when
> creating the real parser instance. But, so, if we have it in SAXParser,
> we should also have it in DocumentBuilder (for simmetry). Again, JAXP
> 1.1?
Nah -- I don't agree that the DocumentBuilder should throw SAXException. I
see the DOM and SAX classes actually diverging a bit from their initial
symmetry. I don't think that we need to do strict mirroring just for the
sake of such.
> The only "issue" I see right now in having two implementations is that
> Sun's RI will probably default to Project-X, in case no System property
> is found, while mine defaults to Xerces. Given the fact that there is no
> "easy" way for specifying system properties in the current JDKs up to
> 1.2 (apart from command line options), depending on the JAXP
> implementation you choose, you have a default parser.
Yep. This is an issue that we need to hit for JAXP 1.1 (hopefully).
> What I want to be able to have is to be able to compile a XML enabled
> application regardeless of what parser you have in your CLASSPATH, and
> then running it, again, regardeless of what JAXP implementation (and so
> default parser) you have.
Well, you've got that now :) Unless you cast that is to take advantage of
implementation specifics.
.duncan
Re: HELP - How to delete an attribute having default value?????????
Posted by Arnaud Le Hors <le...@us.ibm.com>.
You can't. The whole purpose of a default attribute is to be there by
default! The only way to really get rid of it is to use a DTD in which
there is no such a default attribute.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
HELP - How to delete an attribute having default value?????????
Posted by Indrajit Chaudhuri <In...@catsglobal.co.in>.
Hi,
I am using Xerces C++ parser for my application. I want to delete an
attribute from the DOM tree corresponding to the XML file, but since the
attribute has a default value as supplied by the DTD, I am not able to
delete it. Is there any way to remove the attribute from the DOM tree?
TIA for your help!!
Regards,
Indrajit
Re: Public Release 1 comments and implementation
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
James Duncan Davidson wrote:
>
> > on page 21 the method SAXParser.getParser() is declared to throw a
> > SAXException, but later on, on page 23, that exception is not reflected
> > into the documentation. I believe the mistake resides on page 21,
> > because nothing should happen in the getParser() method but returning
> > the already instantiated and configured Parser() instance to the caller.
>
> Unfortunatly, the mistake is on page 23. In the javax.xml.parsers
> documentation, we define the getParser method to throw the exception. The
> ommission on the method description is erroneous.
Unfortunately :) Probably in version 1.1 it'll be removed. Anyway, as
long as the two descriptions are coherent, it's good for me.
> > Also, I don't understand why the SAXParserFactory.newSAXParser() should
> > throw a SAXException, while DocumentBuilderFactory.newDocumentBuilder()
> > doesnt. Those methods already throw a ParserConfigurationException, so,
> > in my very humble opinion, the SAXException is redundant.
>
> The SAXException is intended to be thrown by the underlying SAX
> implementation while the ParserConfigException is thrown by the factory in a
> condition where the set configuration isn't valid. It is arguable redundant
> and we might want to address this in a future rev of the API.
I agree with you on that, in fact, expecially when considering SAX2
properties and features, SAXExceptions come always into play when
creating the real parser instance. But, so, if we have it in SAXParser,
we should also have it in DocumentBuilder (for simmetry). Again, JAXP
1.1?
> > The last thing, I developed an implementation for the Apache XERCES
> > parser, both of the javax.xml.parser classes, and for their relative
> > implementation under the org.apache.xerces.jaxp package. If you could
> > give them a look and send me some feedback that would be greatly
> > appreciated (I implemented the javax.xml.parser classes also since
> > there's not an implementation currently available conforming to the
> > given spec, as far as I can see).
>
> Nope, there's not a .jar file that implements the spec avaialble yet. It'll
> be out with the JAXP reference implmenetation "Real Soon Now". There isn't
> an issue for you having your own implmentation, though when we do get our
> jaxp.jar out there, you'll probably want to pick it up so that you don't
> have to maintain those interfaces. :)
The only "issue" I see right now in having two implementations is that
Sun's RI will probably default to Project-X, in case no System property
is found, while mine defaults to Xerces. Given the fact that there is no
"easy" way for specifying system properties in the current JDKs up to
1.2 (apart from command line options), depending on the JAXP
implementation you choose, you have a default parser.
What I want to be able to have is to be able to compile a XML enabled
application regardeless of what parser you have in your CLASSPATH, and
then running it, again, regardeless of what JAXP implementation (and so
default parser) you have.
Let's say that ANT.next uses JAXP. You have Project-X in your CLASSPATH,
and you develop and compile ANT using it. When it comes to me, and I use
XERCES, if we use the same JAXP classes, I will be forced to start ANT
either with one more command line option, otherwise I will be required
to have Project-X, because the JAXP classes default to it (and I would
get not even an exception, but an Error!).
So, since it's 4 classes, and they're really trivial to write, I'd see
every parser distributed with a "localized" copy of those, with the
appropriate default.
If the R.I. allows to "customize" the default (a properties file?), I'll
be more than happy to drop it, but, if not, until JDK-1.4 (where I
believe you'll be able to write system properties in a jdk-wide
configuration file), I'd say, let's keep different implementations.
Thanks.
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Public Release 1 comments and implementation
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> on page 21 the method SAXParser.getParser() is declared to throw a
> SAXException, but later on, on page 23, that exception is not reflected
> into the documentation. I believe the mistake resides on page 21,
> because nothing should happen in the getParser() method but returning
> the already instantiated and configured Parser() instance to the caller.
Unfortunatly, the mistake is on page 23. In the javax.xml.parsers
documentation, we define the getParser method to throw the exception. The
ommission on the method description is erroneous.
> Also, I don't understand why the SAXParserFactory.newSAXParser() should
> throw a SAXException, while DocumentBuilderFactory.newDocumentBuilder()
> doesnt. Those methods already throw a ParserConfigurationException, so,
> in my very humble opinion, the SAXException is redundant.
The SAXException is intended to be thrown by the underlying SAX
implementation while the ParserConfigException is thrown by the factory in a
condition where the set configuration isn't valid. It is arguable redundant
and we might want to address this in a future rev of the API.
> The last thing, I developed an implementation for the Apache XERCES
> parser, both of the javax.xml.parser classes, and for their relative
> implementation under the org.apache.xerces.jaxp package. If you could
> give them a look and send me some feedback that would be greatly
> appreciated (I implemented the javax.xml.parser classes also since
> there's not an implementation currently available conforming to the
> given spec, as far as I can see).
Nope, there's not a .jar file that implements the spec avaialble yet. It'll
be out with the JAXP reference implmenetation "Real Soon Now". There isn't
an issue for you having your own implmentation, though when we do get our
jaxp.jar out there, you'll probably want to pick it up so that you don't
have to maintain those interfaces. :)
.duncan
----------------------------------------------------------------------
James Duncan Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do();