Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Dave, Before responding to your specific proposal ... I do not understand why you are creating a new interface like ModParser instead of just evolving the Parser interface itself. Personally, while I know full well what it would mean to implement Parser -- a "ModParser" is just plain confusing. Five years from now, someone should not have to know the history of SAX to understand the terminology. Now to the Predefined features... In a message dated 3/7/99 7:13:19 PM Eastern Standard Time, david@m... writes: > 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. I like the idea of SAX filters but still feel that you should allow access to a DOM Document if the implementing Parser can supply one. I won't restate the suggestion here as it was covered in a previous email. However; that could greatly simplify a filter-writer's job. > > 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: Since some finite set of SAX features will not approach a global naming problem, I strongly urge not to use a URI. If a package name scheme is to be used, something like "sax.feature.validation". It would also be nice to provide one word String constants for the standard features. Best wishes, - Mike Daconta (mdaconta@a...) 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...)
|
