[jdom-interest] SAXHandler's Stack to be protected ?
paul at ags.uni-sb.de
Tue Aug 21 13:22:54 PDT 2001
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 JSR-102
> not just an implementation, but also a specification. That is, a subclass
> that conforms to the specification should interoperate with any
> (I've also suggested that an object serialized in one implementation
> deserialize in another implementation, but since SAXHandler isn't
> Serializable, that's neither here nor there.)
More information about the jdom-interest