ModSax Suggestion

[Bill la Forge]

Seems like a good fit for filters--drop what you don't
want, transform the rest as needed.

Bill

-----Original Message-----
From: David Brownell <db at eng.sun.com>
To: MikeDacon at aol.com <MikeDacon at aol.com>
Cc: xml-dev at ic.ac.uk <xml-dev at ic.ac.uk>
Date: Friday, March 05, 1999 5:58 PM
Subject: Re: ModSax Suggestion


>Interesting suggestion for a big hole in the parts of
>the Java API set that are more or less "standard" at
>this poit -- SAX and DOM.
>
>One comment though:  I've found that it's important to
>be able to have options controlling how the DOM tree is
>built.  For example, whether to discard ignorable spaces,
>or do namespace conformance enforcement, or try to get
>CDATA sections (comments, etc).
>
>Accordingly, I think being able to do a bit more than
>this will be important.
>
>- Dave
>
>
>
>MikeDacon at aol.com wrote:
>> 
>> Hi Everyone,
>> 
>> While SAX does a good job as an event-based interface
>> to Parsers, it would be nice to add a few methods to
>> receive a DOM representation back from a reference to an org.xml.sax.Parser.
>> 
>> Something like:
>> 
>> org.w3c.dom.Document  parse(InputSource  is, boolean events) throws
>> SAXException;
>> org.w3c.dom.Document  parse(java.lang.String uri, boolean events) throws
>> SAXException;
>> /* the events boolean would be to turn on/off event calls. */
>> 
>> If a SAXDriver did not want to produce a DOM, it could either simply
>> return a null or a method added like:
>> 
>> boolean isDomCapable();
>> 
>> The above would let me use the ParserFactory to seamlessly switch
>> between Parser implementations and get a DOM tree without building
>> one myself.  It is fruitless for me to build a DOM tree when almost all
>> the parser implementations provide that ability.  I just want a way to get
>> at that functionality in a simple and standard way (thus SAX).
>> 
>> Thoughts?
>> 
>>  - Mike
>> -----------------------------------------------
>> Michael C. Daconta
>> Author of Java 2 and JavaScript for C/C++ Programmers
>> Author of C++ Pointers and Dynamic Memory Management
>> Sun Certified Java Programmer and Developer
>> http://www.gosynergy.com
>> 
>> 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)
>
>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)
>


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)