Cart
[Home] [By Thread] [By Date] [Recent Entries]
> This leads to another thought -- that we probably need some kind of a
> hook for requesting and/or querying parser features. This issue came
> up before during the initial SAX 1.0 design. Something like the
> following might be appropriate:
>
> package org.xml.sax;
>
> public interface Parser {
> ...
> public boolean hasFeature (String featureName);
> public boolean requestFeature (String featureName, boolean status);
> }
We designed this kind of mechanism into ODBC. Because of the large number of
optional features, it is quite difficult to write truly generic ODBC code. I
believe this was justified in ODBC's case because we wanted to work with a large
variety of existing databases that had a tremendous range of capabilities.
I don't think the same situation applies to SAX. SAX is still fairly young and
we have a better chance to dictate/agree on required features, so we should
avoid optional features as long as possible. (WRT namespaces, we should either
design around them or simply require parsers to support them.)
-- Ron Bourret
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
