ModSAX (SAX 1.1) Proposal

[David Megginson]

Don Park writes:

 > Here is my counter proposal:

Thank you very much for the input, and for the opportunity to explain
my thinking a little more.

 > public interface ModularParser extends Parser {

 >     boolean hasModule(String moduleName);
 >         // returns true if the named module is supported, false otherwise.
 >         // return value does not indicate whether the module is enabled or
 > not.
 >         // module version should be encoded in the module name

What exactly do you mean by a "module"?


 >     boolean getModuleState(String moduleName);
 >         // returns true if the named module is enabled, false otherwise.
 > 
 >     boolean setModuleState(String moduleName, boolean enable);
 >         // enables or disables a named module.
 >         // Result reflects the resulting state of the module.

I deliberately avoided the first one, because I didn't want parsers to
be forced to have a determinate state.  For example, it is possible
for

  parser.setFeature("org.xml.sax.features.validation", true)

and

  parser.setFeature("org.xml.sax.features.validation", false)

both to fail.  This is exactly what will happen in my helper class for 
adapting SAX 1.0 Parsers.  The default value will always be "don't
know, don't care", since there will always be features that drivers
don't know about and about which they cannot give a correct true/false 
answer.

 >     ModuleHandler getModuleHandler(String moduleName);
 >         // returns named module's handler or null if there is no previously
 > installed
 >         // handler or if the module is not supported.

In general, we don't have get* methods for org.xml.sax.Parser -- is
there a special reason that we need one here?

 >     boolean setModuleHandler(String moduleName, ModuleHandler handler);
 >         // sets named module's handler.
 >         // returns true if successful or false if failed to set the handler
 > due to
 >         // lack of support or other reasons.

I prefer to throw an exception rather than returning a boolean, but
that's very much a personal prejudice.  My rationale is that it's
harder to forget about an exception than it is to ignore a boolean
value; a programmer in a hurry can easily write

  setModuleHandler("org.xml.sax.handlers.namespace", handler)

and forget to check the return value, but if the programmer forgets to
catch an exception, the compiler will likely complain loudly (unless
the current method already throws that exception or its supertype).

 >     // following two might be more controversial but they are definitely
 > useful.
 > 
 >     Object getModuleProperty(String moduleName, String propName);
 >     boolean setModuleProperty(String moduleName, String propName, Object
 > propValue);
 > }

In the case of handlers, it makes more sense to set properties
directly on the handler objects; in the case of features (like
namespaces), I agree that there does need to be a way to set
properties to values other than true or false.

How about this:

public interface ModParser extends Parser
{
  public abstract void setFeature (String featureID, boolean state)
    throws SAXNotSupportedException;
  public abstract void setParameter (String parameterID, Object parameter)
    throws SAXNotSupportedException;
  public abstract void setHandler (String handlerID, ModHandler handler)
    throws SAXNotSupportedException;
}

Setting up a parser for namespace processing might look something like
this:

  try {
    parser.setFeature("org.xml.sax.features.namespaces", true);
    parser.setParameter("org.xml.sax.parameters.namespaces.separator", 
                        " ");
    parser.setHandler("org.xml.sax.handlers.namespace", handler);
  } catch (SAXNotSupportedException e) {
    System.err.println("Parser does not support namespace handling.");
  }

It certainly looks cleaner than checking a lot of boolean return
values, and it provides stronger compile-time checking as well.


Thanks, and all the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.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)