com.sun,xml.parser LexicalEventListener improvements

[David Brownell]

Actually, that was for the context of the SAX2 discussions ... 
there's a thread I need to read (I was out on vacation while
it was happening!) at

     http://www.lists.ic.ac.uk/hypermail/xml-dev/9903/0580.html

The API mentioned below was essentially an earlier version of the
proposal noted above.  I expect that that the standard extension
will follow SAX2 ... although I could get surprised on either front.

So let me re-cast the question:  should the SAX2 LexicalHandler
stuff work as suggested below?

- Dave


Peter Wilson wrote:
> 
> I believe that the class LexicalEventListener is the proposed basis for
> the new javax.xml extension. In private conversation with Dave Brownwell
> of Sun Microsystems I made the suggestions below. While refusing these
> ideas Dave suggested that I poll the users on XML-DEV to determine their
> reactions. I hope you will agree with these suggestions and contact Dave
> 
> via xml-feedback at java.sun.com.
> 
> 1. The startElement() method should indicate if it is an empty element.
>     i.e. whether the element ends with a /> tag or not.
> 
> 2. The proposed LexicalEventListenser interface should have new methods
>     startPCDATA() and endPCDATA(). Calls to these methods would bracket
> calls to the current characters(...) method. The LexicalEventListener
> interface already contains bracketing calls for start/endCDATA - why the
> inconsistency?
> 
> <ALTERNATIVE>
> Better yet, the characters(..) method should be split into two:
> CDATA(...) and PCDATA(..). The two method sets would then be
> startPCDATA(), PCDATA()*, endPCDATA. ditto for CDATA.
> </ALTERNATIVE>
> 
> <ALTERNATIVE>
> Alternatively a single set: startCharacters(), characters(),
> endCharacters()
> could be used with a flag on startCharacters to indicate parsed or
> unparsed text.
> </ALTERNATIVE>
> 
> Dave argues that these method calls may be implemented by writing an
> event filter to restructure the events as required. By this logic,
> current extensions to LexicalEventListener are all equally pointless.
> Was the addition of the start/endCDATA methods added solely for his
> convenience in implementing XMLDocumentBuilder? Using the same argument
> they should not be cluttering up the new interface.
> 
> My argument is that the new XML parsing facilities should not be skewed
> by the need of one application (e.g. building Dom models).  This is best
> achieved by structuring lexical events for ALL syntactic structures.
> The current LexicalEventListener interface is a step in the right
> direction but is not complete.
> 
> Peter Wilson
>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)