xml-dev - Re: SAX RFD: ModSAX Predefined Features

["John Wilson" <tug@wilson.co.uk>]

----- Original Message -----
From: David Megginson <david@megginson.com>
To: XML Developers' List <xml-dev@ic.ac.uk>
Sent: 07 March 1999 23:56
Subject: SAX RFD: ModSAX Predefined Features


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

It seems to me that there are two kinds of parser extensions:

1/ those that are static (i.e. must be established before the parser is
used)
2/ those that are dynamic (i.e. they can be changed on the fly)

An example of a static extension would be buffering. If the parser is
buffering input then it is infeasible to change to unbuffered input in the
middle of parsing the text. Switching from non validating to validating is
problematic, insisting that a parser be able to do this would probably add
unacceptable overhead to the non validating mode.

I would suggest that the bulk of the extensions should be specified to the
parserFactory and only a *very* limited number (if any at all) be specified
to the instance of Parser.

I would very much like a getFeature function which returns a value telling
me if the feature is set or not.

I'm also not very keen on the use of strings to specify the features.

How about using instances of classes:

in org.xml.sax

public abstract class Feature {
  public Feature(boolean state) {
    this.state = state;
  }

  final boolean state;
}

public final class Validation extends Feature {
  public Validation(boolean state) {
    super(state);
  }
}

individual parser implementations would then be free to add their own
extensions defined by classes that subclass org.xml.Feature - they could
also contain parameters.

setFeature would then take a single Feature parameter:

    xxx.setFeature(new org.xml.sax.Validation(true));

getFeature would take a Class parameter and return an instance of the class
or null if the feature was unrecognised.

org.xml.sax.Feature f = xxx.getFeature(org.xml.sax.Validation.class);

if (f == null) // not supported
if (f.state) // supported and switched on.

non Java implementations would probably have to use a string instead of the
Class parameter.

John Wilson
The Wilson Partnership
5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
+44 1296 641072, +44 976 611010(mobile), +44 1296 641874(fax)
Mailto: tug@wilson.co.uk






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)