SAX RFD: ModSAX Predefined Features

Lars Marius Garshol larsga at
Mon Mar 8 10:29:39 GMT 1999

* David Megginson
| The value of featureID will in some way piggyback on DNS, either by
| using URIs or by using names similar to Java packages.

I think we should use package-like names.  Using protocol prefixes
seems to me both potentially confusing, slightly obfuscating and I
don't see the merit in it over a package-like scheme.

I much prefer org.xml.sax.features.validation over

| 2.

I agree with James that separating general entities and parameter
entities is a good idea.

| 4.

I'm not sure I see the merit of this. Maybe we should skip this?

A suggestion of my own:


True means read the default catalog file, whether that is located via
an environment variable, a Java property or something else.  OpenXML,
XML Parser for Java (xml4j) and xmlproc already support catalogs, and
might find this useful.  xmlproc certainly will.
| No SAX parsers will be *required* to support any of these -- they
| can simply throw a SAXNotSupportedException for any request 

I also agree with James that a separate unrecognized-exception is a
good idea.

| Unlike parsers, filters will ordinarily pass unrecognised feature
| requests on up the chain of responsibility.

Good point. This implies that filters need references in both
directions, that is, both to the event source and to the event
receiver, thus resolving a question that was previously discussed
| [1]

Hmmm. Wouldn't this reference be more correct?


--Lars M.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list