[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: com.sun,xml.parser LexicalEventListener improvements

• From: David Brownell <db@e...>
• To: Peter Wilson <pwilson@g...>
• Date: Fri, 02 Apr 1999 09:46:22 -0800

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@j....
> 
> 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@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • com.sun,xml.parser LexicalEventListener improvements
    • From: pwilson@g... (Peter Wilson)

• Prev by Date: Re: How can I extract data from a XML Document
• Next by Date: XML is broken (was Re: Why Doesn't IE5 use the DTD to Validate?)
• Previous by thread: com.sun,xml.parser LexicalEventListener improvements
• Next by thread: com.sun,xml.parser LexicalEventListener improvements
• Index(es):
  • Date
  • Thread