SAX RFD: ModSAX Predefined Features
Lars Marius Garshol
larsga at ifi.uio.no
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. http://xml.org/sax/features/external-entities
I agree with James that separating general entities and parameter
entities is a good idea.
| 4. http://xml.org/sax/features/unbuffered-input
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
| 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
|  http://www.lists.ic.ac.uk/archives/xml-dev/9902/0627.html
Hmmm. Wouldn't this reference be more correct?
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev