xml-dev - SAX RFD: ModSAX Predefined Features

[David Megginson <david@megginson.com>]

What:   Four proposed predefined features for ModSAX
Action: Please read and comment (especially to propose core features
        I've missed)

Last month, I posted a proposal [1] for a backwards-compatible SAX
layer called ModSAX, which will allow parser and filter writers to
extend SAX and application writers to discover what extensions exist,
all in a well-defined and predictable way.

The relevant part of that interface for this posting is the following
method in ModParser (which extends org.xml.sax.Parser):

  public abstract void setFeature (String featureID, boolean state)
    throws SAXNotSupportedException;

The value of featureID will in some way piggyback on DNS, either by
using URIs or by using names similar to Java packages.  Although
people will be allowed (and encouraged) to invent their own features,
I'd like to predefine a core set of features for the next SAX
release.  Here's what I've thought of so far:

1. http://xml.org/sax/features/validation
  True means validate, false means don't validate.

2. http://xml.org/sax/features/external-entities
  True means expand external text entities, false means don't expand
  external text entities.

3. http://xml.org/sax/features/namespaces
  True means perform namespace processing -- munge element and
  attribute names and remove namespace declaration attributes -- and
  false means don't perform namespace processing.

4. http://xml.org/sax/features/unbuffered-input
  True means ensure that the parser does not buffer input from a
  Reader or InputStream supplied by the application (actually,
  one-character look-ahead will usually be required); false means do
  not ensure that the parser does not buffer input.  This feature might
  be useful for reading multiple documents from a single stream.

No SAX parsers will be *required* to support any of these -- they can
simply throw a SAXNotSupportedException for any request (as they
should for any other unrecognised feature request).  The earliest
ModSAX parser will probably be a general-purpose SAX 1.0 Parser
adapter, and that will certainly not be able to do anything useful
with these.

Unlike parsers, filters will ordinarily pass unrecognised feature
requests on up the chain of responsibility.


Examples
--------

If an application wants to ensure that the SAX parser is performing
validation, it can use

  try {
    parser.setFeature("http://xml.org/sax/features/validation", true);
  } catch (SAXNotSupportedException e) {
    // ...
  }

The parser may throw an exception for either of two reasons:

1. it cannot validation; or

2. it does not recognise the property.

If the application wants to determine which of the two is the case,
then it can try the following:

  try {
    parser.setFeature("http://xml.org/sax/features/validation", false);
  } catch (SAXNotSupportedException e) {
    // ...
  }

If the parser throws an exception again, then it does not recognise
the property name (in other words, it may or may not perform
validation, and the application has no way to tell); if the parser
does not throw and exception, then it simply does not support
validation.


[1] http://www.lists.ic.ac.uk/archives/xml-dev/9902/0627.html

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)