Lists Home |
Date Index |
- From: Lars Marius Garshol <email@example.com>
- To: "XML Developers' List" <firstname.lastname@example.org>
- Date: 08 Mar 1999 11:28:52 +0100
* 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: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)