[jdom-interest] SAXHandler's Stack to be protected ?

[Joseph Bowbeer]

Compatible serialization is possible.  The approach is summarized here, I
believe:

  This link is the TODO list, but is the searchable archive down now?
  http://www.servlets.com/archive/servlet/ReadMsg?msgId=7697

(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 ?


>
> Really...
>
> 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.
>
> Paul
>
>
>
> 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
JSR-102
> > is
> > not just an implementation, but also a specification.  That is, a
subclass
> > 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.)
> >