K.Kawaguchi wrote:
Components are managed by a component manager. The
component manager keeps track of the parser state
for features and properties. The component manager
is responsible for notifying each component when
the value of those features and properties change.
I get an impression that I can effectively ignore the reset method and
just rely on the setProperty method, since for any feature/property,
it is saying that the manager is responsible for notifying changes to me.
(assuming that "notifying each component" means "invoking setProperty")
But you are saying that the setProperty method won't be called for
changes between parsing.
That's not what I meant to say. Sorry for the
misunderstanding. Perhaps the last part of that
paragraph should be changed to read:
The component manager
is responsible for notifying each component when
the value of those features and properties change
DURING PARSING.
As well as stating that the component manager
initializes each component before parsing, if it
doesn't say so already.
Speaking of which, did you read the XNI Manual
in the documentation? Do you have suggestions
to improve the content?
So I think my question still stands. For any given property (be it
SymbolTable, ErrorHandler or what not), is there any way to know whether
I should be prepared for it to be changed during parsing or not?
Each component makes up its own mind about what
settings are allowed to be changed during parsing.
In other words, the component does not have to
listen to changes if the changes do not affect the
way that the component operates.
Beyond that, however, we do have a lot of Xerces
components that do NOT change during parsing. But
I don't think we've properly stated that within
the documentation.
I see. Then I think I'm going to ask if it makes sense for the full form
of the property name (PREFIX+PROPERTY) to be defined as well as the
short form (just PROPERTY).
As I wrote, 12 different classes are defining 12 different constants of
the same string. (And I'm just picking up this property randomly and I'm
not trying to show the worst example here.) It seems like a lot of waste.
Or is there any reason why the full form should not be defined as
a constant?
The Java compiler will automatically copy static
final strings from other classes/interfaces into
the class file being compiled. This also applies
to strings that are constructed by using the "+"
operator. But this does take up more space.
I guess making Constants an interface and having
components implement the interface would be more
efficient in that regard. Oh well... I really
don't feel like modifying all of the Xerces code
to change it now.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
