Lists Home |
Date Index |
- From: David Brownell <email@example.com>
- To: Peter Wilson <firstname.lastname@example.org>
- 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
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?
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 email@example.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
> 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.
> Alternatively a single set: startCharacters(), characters(),
> could be used with a flag on startCharacters to indicate parsed or
> unparsed text.
> 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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)