[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX RFD: ModSAX Predefined Features
----- Original Message ----- From: David Megginson <david@m...> To: XML Developers' List <xml-dev@i...> 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@w... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|