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

[Paul Libbrecht]

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