Hi Andy and all,
(Thanks to Elena for resurrecting this thread...) I also like this change,
especially since it will give us an obvious authoritative place to look for
feature default values. Sometimes our documentation has been known to be
inaccurate about these things, and there have been a couple of occasions
I've had to hunt around the source code looking for answers. Clearly, this
wouldn't obviate that need completely, but I think it would help.
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Andy Clark |
| | <[EMAIL PROTECTED]|
| | > |
| | |
| | 08/16/2002 12:10 |
| | AM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Another XNI Change Proposal
|
|
|
|
|
>-------------------------------------------------------------------------------------------------------------------------------------|
Speaking of XNI changes, I would like to propose another
change to the Xerces Native Interface...
I have now written a number of my own parser configurations
with custom parser components (e.g. NekoHTML). And I keep
running into the same problem again and again: even though
the parser configuration can query the settings that each
component supports, it has no way to know what the correct
default value should be.
Therefore, I propose adding the following methods to the
org.apache.xerces.xni.parser.XMLComponent interface:
/**
* Returns the default state for a feature, or null if this
* component does not want to report a default value for this
* feature.
*/
public Boolean getFeatureDefault(String featureId);
/**
* Returns the default state for a property, or null if this
* component does not want to report a default value for this
* property.
*/
public Object getPropertyDefault(String propertyId);
The one thing you might immediately question is my use
of a Boolean object instead of the boolean primitive. I
use this so that the component can state that it doesn't
care what the default value should be. This would be
used in situations where the component may recognize and
use a setting common to the parser configuration and/or
other components, but where it doesn't care what the
default is.
And in fact, only the component that "introduces" the
setting should set its default value. For example, both
"validation" and "namespaces" are system wide settings
and the parser configuration sets the default value. A
lot of the components use these values but will take
whatever default value has been established.
What do you think? Can we roll this change into the
codebase for Xerces 2.1.0?
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
