Lists Home |
Date Index |
- From: MikeDacon@aol.com
- To: firstname.lastname@example.org, email@example.com
- Date: Sun, 7 Mar 1999 21:31:07 EST
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
Now to the Predefined features...
In a message dated 3/7/99 7:13:19 PM Eastern Standard Time,
> 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  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.
- Mike Daconta (firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)