ModSAX: Proposed Core Properties

[MikeDacon at aol.com]

Hi David,

In a message dated 3/9/99 8:30:31 PM Eastern Standard Time,
david at megginson.com writes:
> http://xml.org/sax/properties/dom-node <Node> (read-only)
>    Get the DOM node currently being visited, if the SAX parser is
>    iterating over a DOM tree.  If the parser recognises and supports
>    this property but is not currently visiting a DOM node, it should
>    return null (this is a good way to check for availability before the 
>    parse begins).
>  

This has made me realize that I was under a misconception about
what the generic get() and set() parser properties would provide in
terms of functionality.  What I was really hoping for was:

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. */

Which would allow me to code:
try
{
     ModParser mp = ParserFactory.makeModParser();
     boolean supported = true;
     try
     {
             mp.setFeature("http://xml.org/sax/features/dom-result", true);
     }  catch (SAXNotSupportedException snse) { supported = false; }

     if (supported)
     {
          Document d = mp.parse("test.xml", false);
          // ... process Document
     }
} catch (SAXException se)
  {
      // handle it
  }

So, what I'm saying is that I would like to be able to choose 
whether to interface to the Parser via events or via a DOM.
If you agree with this, I believe using the return type is more
appropriate than getting a resultant property (as I suggest next).

If for some reason the above is not palatable, the same could be 
accomplished under the current scheme if we added a 
property:

http://xml.org/sax/properties/dom-document <org.w3c.dom.Document> (read-only)

Then I could code:

try
{
     ModParser mp = ParserFactory.makeModParser();
     boolean supported = true;
     try
     {
             mp.setFeature("http://xml.org/sax/features/dom-capable", true);
     }  catch (SAXNotSupportedException snse) { supported = false; }

     if (supported)
     {
          mp.parse("test.xml");
	    Document d = (Document) mp.get("http://xml.org/sax/properties/dom-
document");
          // ... process Document
     }
} catch (SAXException se)
  {
      // handle it
  }

Note: both code examples also required an added feature to check
for the desired functionality.

I believe the above is sorely missing from the current API.  Does
anyone else see a need for this?  If not, why not?  But before you
say, "build a layer on top of SAX" -- to me that seems ridiculous when most 
of the Parser implementations can produce a dom Document.

Best wishes,

 - Mike (mdaconta at aol.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)