[jdom-interest] SAXHandler's Stack to be protected ?
jozart at csi.com
Tue Aug 21 16:27:58 PDT 2001
Compatible serialization is possible. The approach is summarized here, I
This link is the TODO list, but is the searchable archive down now?
(I based the approach on info in Josh Bloch's Effective Java Programming
book. Dennis Sosnoski provided details.)
As for what is a JSR (a spec or just an implementation?), I try to bring
this question to our attention every now and again...
----- Original Message -----
From: "Paul Libbrecht" <paul at ags.uni-sb.de>
To: "Joseph Bowbeer" <jozart at csi.com>
Cc: <jdom-interest at jdom.org>
Sent: Tuesday, August 21, 2001 1:22 PM
Subject: Re: [jdom-interest] SAXHandler's Stack to be protected ?
> Indeed that's interesting but I am not sure JSR's are specifications,
> though it might say so. It would surely be great to have compatible
> serialization but, at the current stage, this is rather impossible. The
> whole quality work that JDOM makes to allow developer to really manipulate
> XML documents (as opposed to the relatively delicate SAX (in the sense of
> delicate to program) or the absolutely inmanipulable DOM trees).
> I believe JDOM has now to focus on its sole implementation with all
> possible and thinkable usages. Making it an abstract specification to
> allow different implementations is, I would say, a task for later.
> Folks that use JDOM use it because it is simple and it works. If you did
> not have either of them, the use crowd woud just be lost...
> Opposed to this you have the very many folks who deliver (or did deliver)
> XML tools that were based on some parsers and often did not include it
> (like the former XML4j...). JDOM provides a perfect reply to this:
> currently you can't change JDOM but you can change the parser rather
> easily... and the need to change JDOM will most probably come... later.
> On Tuesday, August 21, 2001, at 07:43 AM, Joseph Bowbeer wrote:
> > Paul Libbrecht writes:
> >> De-private-ising the stack member (or having a "currentElement"
> >> accessor) would allow me to stick to this very economic philosophy.
> > Just keep in mind, as more of the implementation is exposed, that
> > is
> > not just an implementation, but also a specification. That is, a
> > that conforms to the specification should interoperate with any
> > implementation.
> > (I've also suggested that an object serialized in one implementation
> > should
> > deserialize in another implementation, but since SAXHandler isn't
> > Serializable, that's neither here nor there.)
More information about the jdom-interest