SAX RFD: ModSAX Predefined Features

[MikeDacon at aol.com]

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 at megginson.com 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 at aol.com)

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